> The ability to apply a wildcard match on the s3:ResourceAccount condition key
That’s the crazy part. No good can ever come from this - there is no legitimate reason why you would grant or deny permission based on a partial account id match.
That’s the crazy part. No good can ever come from this - there is no legitimate reason why you would grant or deny permission based on a partial account id match.
Anyway, this discussion is a bit amusing to me, since Devops people are discovering side channels[1] now, although other types of side channels such as speculative execution side channels on CPUs (Meltdown, Spectre) already made waves at the time of discovery, and before that we had power analysis[2] and Magnetostriction detection, and constant time cryptography (this one is a field of its own, so I omit references.)
[1] https://en.m.wikipedia.org/wiki/Side-channel_attack [2] https://en.m.wikipedia.org/wiki/Power_analysis
That is correct.
The IAM condition language is flexible and does not prevent you from doing strange things.
Doing glob matching on account IDs is like doing concatenation with guids, applying a bitshift to a UTF8 string, or running a regex on an integer. It is a nonsensical operation, and - as shown here - results in surprising security properties of the resulting system.
Surprising security properties are an undesirable result in an access control policy language.
We, the DevOps people, already knew about side channel attacks, Spectre and the likes, evaluated the performances hit for the fixes (or alleged fixes), patched our kernel boot params etc etc. We are curious people, just like many here.
Well we are, if nothing, consistent.
The next nerd who pinches and inch of the coder/ops divide is going to make a billion.
It's amazing how anything got made considering how disjointed processes used to be.
Not GP, I tried to answer as friendly as possible. Their approach is even more weird given that Security goes really hand in hand with systems infrastructure In any small enough organization, security will be managed by devops/sre. If the org becomes large enough, it will start dedicating people to Security.
It used to be really bad... "works on my machine", bad deploy instructions etc. We paved a lot of these roads with (really fucking bad) strategies like containers. At some point maybe we will learn to write software that is operationalizable. Projects like tigerbeetle give me hope that this is our next evolution.
You're not a fan of my AWS lottery idea where accounts ending in 666 get access to a free bitcoin miner??
Odds are that an account wildcard match like 676363687* will just match a few hundred entirely random AWS accounts.
Honestly, wouldn't surprise me that much if they were willing to accommodate this if for sufficiently large accounts. It'd still pretty sketchy to design your access control around, but it wouldn't be unrealistic.
Given the way these IaaSs' distributed KV stores all manage writes (i.e. by having a cluster of transactor nodes that per-key write-linearization responsibility for parts of the keyspace is sharded across — such that writes are fanned out to a particular designated transactor-node given the key's hash-slot), a very large S3 user, generating an extremely high level of metadata-update concurrency against a bucket, could very likely write-contend that bucket's metadata / have a "hot" bucket-metadata key; experience low perf due to that; and solve that by sharding the bucket (swapping one too-hot metadata key for N somewhat-hot metadata keys.)
I want to give an intuition-building example here, of an IaaS feature that wouldn't exist / wouldn't be exposed to the user if not for object-storage buckets being metadata-write-contended at scale. I'm not very familiar with the AWS ecosystem, though, so I'm not sure what the good example is for AWS. What I do know is GCP, so here's a GCP example: Google Cloud Dataflow allows you to set a temporary workspace GCS bucket on a per-job basis (gcsTempLocation). And, IIRC, Google's Cloud Architects advise to not have a bunch of active Dataflow jobs sharing the same gcsTempLocation — regardless of whether they use distinct key prefixes to namespace the temp files. Given that each job would be doing a lot of little serial updates to the temp bucket — and given that Dataflow jobs can each be highly internally concurrent — you're already potentially putting out O(N^2) ~concurrent updates to that bucket. You really don't want to make it O(N^3).
filter = property, operand, value
Sharding on account ID might make sense if someone has a large number of them, but that would not necessitate wildcard matching.
Either you bucket by an internal ID and give the user a hash, or you give the user an ID and bucket by your internal hash.
Users have no business knowing your sharding scheme.
As it is my side project’s side project I do what is easy so these operators are always available even in cases where they don’t make sense (I dunno what happens if you try a regex query on a number, I don’t care) I can imagine there is something a bit like this inside AWS but for a security-sensitive system with a lot of users you have a different standard.