Perl 6 - the future is here, just unevenly distributed

IRC log for #confidant, 2016-02-25

| Channels | #confidant index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
14:02 DanyC joined #confidant
19:06 lyftbot left #confidant
19:06 lyftbot joined #confidant
21:55 abrody does anyone have suggestions for how to debug issues with the KMS grants?
21:56 abrody currently seeing `AccessDeniedException` when calling the GenerateRandom operation: User: arn:aws:iam::123:user/confidant-blah is not authorized to perform: kms:GenerateRandom
21:56 abrody looking at the key policy it sure looks like kms:GenerateRandom is granted to that user
22:15 heph left #confidant
22:17 abrody for the time being I just added kms:GenerateRandom * for that user globally, not sure if that's the appropriate thing to do
22:24 Ryan_Lane abrody: ah
22:24 Ryan_Lane yeah, the grants don't handle generate random
22:25 abrody got it, should that be part of the recommended confidant-production role?
22:25 Ryan_Lane yep
22:25 Ryan_Lane it's in the docs directly on the key policy
22:25 Ryan_Lane http://lyft.github.io/confidant/basics/configuration/#kms-key-policy-configuration
22:26 Ryan_Lane you don't have to use the key policy for this, though. for most of what you can do in the key policy you can also do in IAM policy or key grants
22:26 Ryan_Lane I find IAM policy to be the most flexible, but it's poorly documented in AWS
22:26 abrody so I do have kms:GenerateRandom in the key policy, but that didn't seem to be sufficient
22:27 abrody or maybe there's something that I wasn't understanding about it
22:27 Ryan_Lane @abrody when you say user... are you using an IAM user, or an IAM role?
22:28 abrody long story, there's actually both an IAM user and an IAM role, but both should be covered
22:28 abrody the user is what I'm using for the time being
22:28 Ryan_Lane gotcha
22:28 Ryan_Lane so your key policy have GenerateRandom for both the user and the role?
22:30 abrody yeah
22:31 Ryan_Lane yeah. it looks like I have generate random on my IAM policy
22:31 Ryan_Lane you know what? I think this is global to the service and not specific to any key
22:31 Ryan_Lane which is why it's useless on the key policy
22:31 abrody yeah, when I used the built in KMS key policy generator wizard thingy it didn't include GenerateRandom in the policy
22:32 Ryan_Lane I'm going to open an issue for this. I need to update the docs
22:35 Ryan_Lane abrody: https://github.com/lyft/confidant/pull/46
22:35 Ryan_Lane look accurate?
22:37 abrody @Ryan_Lane I also ended up adding kms:ListGrants and iam:GetRole in addition to kms:GenerateRandom
22:38 abrody do you know if those are also necessary?
22:38 Ryan_Lane ah. yes. I have GetInstanceProfile and ListInstanceProfiles
22:38 Ryan_Lane but that's incorrect
22:39 Ryan_Lane grants should be handled via the key policy
22:40 abrody I'll double check to see if I can remove those, I also had an extra condition in the key policy created by the wizard that turned out to be problematic and which I later removed
22:40 Ryan_Lane ah. crap. it's not in the docs
22:40 Ryan_Lane oh wait. yeah it is
22:40 Ryan_Lane "Action" : [ "kms:ListGrants", "kms:CreateGrant", "kms:RevokeGrant" ],
22:41 Ryan_Lane it's in the "Allow attachment of persistent resources" Sid
22:41 Ryan_Lane that's for the auth key and not for the at-rest key
22:42 abrody right, I think I had the problematic Condition in the key policy when I was testing
22:42 * Ryan_Lane nods
22:42 abrody but the iam:GetRole, that's needed?
22:42 Ryan_Lane yeah
22:42 Ryan_Lane just updated that PR
22:42 Ryan_Lane https://github.com/lyft/confidant/pull/46/files#diff-261c62b821b41f913e2491616232e133R259
22:43 Ryan_Lane the instance profile stuff was legacy from before the release
22:53 abrody great
23:07 abrody @Ryan_Lane are there docs on how to use the proof of concept confidant_client.py that ships with the thing?
23:07 abrody e.g. what are from_context and to_context?
23:08 Ryan_Lane it's the IAM roles you're talking from and to
23:08 Ryan_Lane the from should match the service you're fetching
23:08 Ryan_Lane the to context is confidant
23:08 Ryan_Lane it matches what's in the grants
23:09 Ryan_Lane so, if you map credentials to myservice-production, and your confidant role is confidant-production it would be...:
23:09 Ryan_Lane python confidant_client.py -u https://... -k "alias/authnz-production" myservice-production confidant-production
23:10 Ryan_Lane in the next release we're going to have a more opinionated client that can be installed via pip
23:10 Ryan_Lane where ideally the web interface will give you a config file to use with it
23:13 Ryan_Lane you may want to adjust the token lifetime. I think it's 1 minute by default, which if your time isn't sync'd well may not be long enough
23:24 abrody gotcha
23:46 abrody also @Ryan_Lane do you have suggestions for where to start on implementation of SAML support? https://github.com/lyft/confidant/issues/9
23:46 Ryan_Lane hm
23:47 Ryan_Lane https://github.com/sahat/satellizer <-- that's likely the best route to take
23:47 Ryan_Lane or does that not support saml?
23:47 Ryan_Lane oauth :(
23:49 Ryan_Lane it's going to require some refactoring of the auth code
23:49 Ryan_Lane so that the auth method can be configured and the relevant modules are loaded based on that
23:50 Ryan_Lane looks like python-saml is the best bet for that
23:51 Ryan_Lane there's a demo for flask: https://github.com/onelogin/python-saml/blob/master/demo-flask/index.py
23:52 Ryan_Lane but, rather than doing the auth inside of each route, you'd want it to be handled in the auth decorators
23:54 Ryan_Lane I don't currently have a method of testing saml, so it's going to be difficult for me to add

| Channels | #confidant index | Today | | Search | Google Search | Plain-Text | summary