Access control based on Groups (idea)

[joonathan]

Would be good to see some sort of ACL capabilities for example based on IAM groups where Test applications would not have access to Production secrets etc.

As an example "myapp.db.prod" secret should be available only to IAM Groups "Admins" and "Production Environment" but not to "Test Environment" and "Developers". Admin group user should be able to list all secrets in the store.

Maybe somehow doable via transparently managing multiple KMS master keys?

[a5an0]

You can actually already do something like that, but I suspect we could make it easier to manage.

Right now, let's say that you have two KMS master keys, dev and prod. If you do credstash -k dev put myapp.db.dev pass1234, it will do the key wrapping with the dev key (and doing -k prod will wrap with the prod key). now, when it comes time to get the value, KMS will use the correct master key to unwrap the data key. so if a particular IAM principal has access to do KMS.Decrypt with dev, but not with prod, then doing credstash get myapp.db.dev will work, but credstash get myapp.db.prod will fail.

So right now, you can use IAM policy (as well as policy on the keys themselves) to keep groups from accessing each others materials. That said, there are a bunch of things we could do to improve the experience. For example:

• make it easy to set permissions on DDB items at put time, so that a dev-user wont even see the prod keys or be able to fetch the ciphertext
• maybe make it easy to manage KMS master keys through credstash? (so far this has been deliberately left to the user, because you should understand the policy that you put on your master keys)

I love the idea of making it easy to set access control around things in credstash. Right now you can technically do it, but it's kind of ham handed, and you need to know a lot about IAM and KMS to make it work well without either shooting yourself in the foot or letting too many people touch things they shouldn't. What other things do you think would make this easier to manage?

[joonathan]

Thanks for your response.

Indeed, we can get pretty far with specifying the key on put and as it gets resolved correctly during get there is no additional overhead on services/deployment side.

I like your first idea of tracking the permissions on DDB as well. Maybe also make it possible to switch AWS profiles similarly to aws --profile <profile_name> cli usage.

[a5an0]

Support for KMS encryption contexts (#18) was just merged in. This change gives us more nobs to turn with restricting the use of keys. You still have to manage the policy yourself, but the plumbing is there.

[AlWilliamson]

Just a thought, but you can also separate using different tables. For example using a Dev table and a Prod table. That allows use to limit access with IAM at a table level, lets you use the same credential name (i.e. myapp.db) and just make calls specifying the table based on an environment variable (or EC2 Tag). It would also keep list cleaner.

[DanyC97]

i like what @AlWilliamson said, +1

[rmmeans]

You can get even more granular that this right now just using IAM directly. DynamoDB supports record level access - so technically, you could have an IAM role for an app server to access the DDB table, but only for (records) needed for that system - the credstash cli running on that server couldn't ask for the DB password of another product, for instance. See here: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/FGAC_DDB.html specifically with the conditions clauses

[artburkart]

With flags for passing in keys (-k), tables (-t), arns (-n) and/or profiles (p/AWS_PROFILE), I think all the bases have been covered by credstash. With these three/four pieces, I am able to separate access—for example—by AWS region with kms keys, by environment with dynamodb tables, and by users/groups with item conditions in my dynamodb IAM policies. Personally, I think it's convenient that credstash can help establish a default setup, but I don't really think it's necessary for it to generate all the tables, keys, and IAM policies for advanced use cases. As such, I would argue this ticket can be closed.