This goes in the right direction. Still it's not 100% reliable (e.g. S3 isn't logged by default to cloudtrail, probably due to volume). Also, not really interactive. I'm talking mostly about ergonomics. Obviously we can solve the issue and create the right policy - but it's not as easy as it could be. That in turn leads to some people skipping the process and staying with too powerful keys.
Data plane volumes are absurd and then you have to crunch it. I estimated this for my company. But you really wouldn't want to pay to do all that cloud trail processing yourself.
We have some buckets where the cloud trail storage with 1y retention is more than the bucket itself.
Hmm, what I had in mind was rather a tool that would generate a new access key (or some other way to correlate the requests) and record and show me in real time what permissions I need and let me play with that and simulate what API calls would fail with a policy that I'm just writing. Very low volume.
I think that predicates you know everything your libraries, pulled in containers, kube charts, etc are doing... I'd love it if I could just be told what I'm doing and see 'yeah that makes sense' and be alerted to changes.
Karger and Schell in 1974 conceptualised the idea of trap doors built into compilers in their Multics Security Review.
Although Ken Thompson is responsible for popularising the idea through his Turing award speech in 1984.
Edit: Ken Thompson mentions the paper in the acknowledgements of his Turing award speech.
"""
Acknowledgment. I first read of the possibility of such
a Trojan horse in an Air Force critique [4] of the security of an early implementation of Multics. I cannot find
a more specific reference to this document. I would
appreciate it if anyone who can supply this reference
would let me know.
"""
[1] https://www.oreilly.com/library/view/aws-cookbook/9781492092...
[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/access-anal...