Perl 6 - the future is here, just unevenly distributed

IRC log for #confidant, 2017-06-20

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

All times shown according to UTC.

Time Nick Message
00:14 wm-bot146 joined #confidant
00:15 doy joined #confidant
01:49 ilbot3 joined #confidant
01:49 Topic for #confidant is now Secret management for AWS. https://lyft.github.io/confidant | Channel logs at http://irclog.perlgeek.de/confidant/ | No one around? We check channel history and will respond later. Check the channel logs or gitter.
10:32 lyftbot left #confidant
10:33 lyftbot joined #confidant
20:14 lyftbot left #confidant
20:14 lyftbot joined #confidant
20:46 lyftbot [caedus41] @ryan-lane Would you mind helping me resolve an error I'm seeing while using the python client for Confidant? I've set Confidant up to run behind NGinx on an EC2 instance with an ELB in front of it. I can access the instance fine and the web portal works for creating credentials, services, etc. but I can't seem to get the client to work. I've set the `auth_context` in the `~/.confidant` config file to `{"user_type":
20:49 Ryan_Lane hey caedus41
20:50 Ryan_Lane hm
20:51 Ryan_Lane the logging on the server side should give an error that gives you a bit more info about why it fails
20:53 lyftbot [caedus41] It seems that it's failing to decrypt the auth token which causes confidant to send a 403 to the client. I've tried tweaking the configs on both machines to use different keys but to no avail.
20:53 Ryan_Lane one thing I notice is your context is a little wrong
20:53 Ryan_Lane your `from` context needs to match the service you're fetching
20:54 Ryan_Lane so, if you're getting test_service, you need a from context of test_service
20:54 lyftbot [caedus41] Ahh, I did not realize that
20:56 Ryan_Lane I really need to update the client docs
20:56 Ryan_Lane in a few weeks I finally get more time to work on open source, so maybe I'll spend some time updating the docs
21:00 lyftbot [caedus41] I've tried changing the auth context but I get the same error
21:00 Ryan_Lane hm. well, from the perspective of decrypt, it's possible from is disconnected from the service
21:01 Ryan_Lane but, you'd get a 4xx from the route because the service name doesn't match the user
21:01 Ryan_Lane but... it looks like you're getting a decrypt error
21:01 wm-bot joined #confidant
21:01 Ryan_Lane so, the other thing I'm thinking is that your KMS key doesn't delegate IAM access to your root account
21:02 Ryan_Lane KMS key policy is a bit weird
21:02 Ryan_Lane by default it doesn't let IAM roles to use the key for most things
21:03 Ryan_Lane you're running this on your confidant EC2 instance?
21:03 Ryan_Lane and it's using your IAM role credentials on that host?
21:05 lyftbot [caedus41] I have two instances. One is hosting the server and the other is hosting the client.
21:05 Ryan_Lane they both have the same IAM role?
21:05 Ryan_Lane or different ones?
21:05 lyftbot [caedus41] Same role
21:06 Ryan_Lane your key policy looks something like https://lyft.github.io/confidant/basics/configuration/#kms-key-policy-configuration ?
21:07 lyftbot [caedus41] I used that, but then I added the AWS AdministratorAccess policy as well just to make sure I didn't run into any permission issues with that
21:08 lyftbot [caedus41] So it should have permissions to access all services
21:08 Ryan_Lane what version of confidant server and client are you using?
21:09 Ryan_Lane also, you don't have auth or encryption disabled, right?
21:10 lyftbot [caedus41] Client is 1.1.15
21:10 lyftbot Server is 1.1.13 I think (that's the most recent number in CHANGELOG.md)
21:10 lyftbot [caedus41] Auth and encryption are both enabled
21:10 Ryan_Lane cool
21:11 Ryan_Lane client version is a bit old
21:11 Ryan_Lane bah. why don't I have a release notes for the client
21:12 Ryan_Lane that said, I think that version of the client should be fine
21:13 lyftbot [caedus41] Are you sure the client version is old? It seems like it's the most current based on github
21:13 lyftbot https://github.com/lyft/python-confidant-client/blob/master/confidant_client/__init__.py#L29
21:13 Ryan_Lane https://github.com/lyft/python-confidant-client/blob/master/setup.py#L81
21:13 Ryan_Lane bah
21:13 Ryan_Lane opening an issue to eliminate that version location :)
21:14 lyftbot [caedus41] haha!
21:14 Ryan_Lane https://github.com/lyft/python-confidant-client/issues/12
21:15 Ryan_Lane KMS makes this a bit of a pain to debug, because it usually doesn't tell you if you're getting denied access
21:16 Ryan_Lane caedus41: all the errors are on the server side, right?
21:16 lyftbot [caedus41] Correct
21:17 Ryan_Lane you created some credentials, then mapped them to test_service via the interface?
21:17 Ryan_Lane and when you visit the credential in the interface, you can unmask the value of the credential_par?
21:17 Ryan_Lane *credential_pair
21:18 lyftbot [caedus41] One sec. I believe so, but i'm confirming
21:18 lyftbot [caedus41] yep
21:19 Ryan_Lane this may be backwards compatibility biting me
21:19 Ryan_Lane one sec. let me take a look at something
21:20 Ryan_Lane are you running the docker container for confidant server?
21:20 lyftbot [caedus41] Nope
21:21 Ryan_Lane you're installing from git? master? a tag?
21:22 Ryan_Lane newest server version is 1.10.0
21:22 lyftbot [caedus41] From git. For the client I just ran `pip install confidant-client` and for the server I git clone master then `pip install -r requirements.txt`
21:22 Ryan_Lane ah ok
21:24 lyftbot [caedus41] One question I have is about some config values. On the client side, I have auth_key set to the key I created for confidant, which is mapped to the confidant IAM role (the one with admin access). On the server side, in service.env there are two keys - the AUTH_KEY and the KMS_MASTER_KEY.  Right now, all 3 are the same key. Obviously that's not the most secure option, but is it incorrect? And should the client `auth_
21:25 Ryan_Lane this is what my client config looks like: https://gist.github.com/ryan-lane/b23c4536f1a8eeac69a6050601429f77
21:27 Ryan_Lane an annoying inconsistency between the client and the server, for the keys, is that for the client you need to specify the full alias
21:27 Ryan_Lane I'm going to open a bug so that the server can also accept `alias/key_name` in addition to `key_name`
21:28 Ryan_Lane it's fine for AUTH_KEY and KMS_MASTER_KEY to be the same thing, until you decide to split them apart
21:29 Ryan_Lane it's less secure, in the strictest sense, but it should still work
21:30 Ryan_Lane in that config example, the token cache file, of course, can either not be set, or can be some more central location. doesn't need to be in a homedir
21:32 wm-bot GitHub [lyft/confidant] new issue by ryan-lane: KMS key names in config should accept `alias/key_name` https://github.com/lyft/confidant/issues/148
21:32 lyftbot [caedus41] Understood re: auth_key and kms_master_key.
21:32 lyftbot I tried matching your config file but now I'm seeing this error: `botocore.exceptions.ClientError: An error occurred (ValidationError) when calling the GetUser operation: Must specify userName when calling with non-User credentials`
21:32 lyftbot [caedus41] on the client
21:32 Ryan_Lane heh. maybe you can only leave `from:` out if it's user auth and not service
21:33 Ryan_Lane put the `from` back in
21:33 Ryan_Lane this is what I get from copying the config from my user, rarher than from a server
21:33 Ryan_Lane rather*
21:34 lyftbot [caedus41] ```default:
21:34 lyftbot url: https://confidant.website.com
21:34 lyftbot auth_key: alias/ec2
21:34 lyftbot auth_context:
21:34 lyftbot user_type: service
21:34 lyftbot from: confidant-production
21:34 lyftbot to: confidant-production
21:34 lyftbot token_cache_file: '/run/confidant/confidant_token'
21:34 lyftbot assume_role:
21:34 lyftbot region: us-east-1
21:34 lyftbot retries: 0
21:34 lyftbot backoff: 1
21:34 Ryan_Lane I need to spend some time launching a public cluster with all the config in the public repoi
21:35 Ryan_Lane is alias/ec2 the KMS key you're using on the server?
21:35 lyftbot [caedus41] I just created a service called confidant-production from the web portal, and used ran
21:35 lyftbot `confidant get_service --service confidant-production`
21:35 lyftbot [caedus41] Yes
21:35 lyftbot [caedus41] Oh, on the server it's just `ec2`
21:35 Ryan_Lane gotcha
21:35 lyftbot [caedus41] no alias
21:36 Ryan_Lane `AUTH_KEY` is `ec2` and `KMS_MASTER_KEY` is `ec2`?
21:36 lyftbot [caedus41] correct
21:38 lyftbot [caedus41] Got it!
21:38 Ryan_Lane on the client and server: curl 169.254.169.254/latest/meta-data/iam/info
21:38 Ryan_Lane oh?
21:39 lyftbot [caedus41] I think I have the auth_context on the server incorrect
21:40 Ryan_Lane ah. yeah, that'll do it
21:40 lyftbot [caedus41] I just ran `get_service` successfully though
21:40 Ryan_Lane awesome
21:40 lyftbot [caedus41] Thank you very much!
21:40 Ryan_Lane yw :)
21:40 Ryan_Lane btw, once you get this working, this is also how our BLESS implementation works
21:40 Ryan_Lane if you need a way to handle SSH :D
21:41 lyftbot [caedus41] We do indeed. I'll take a look at it!
21:41 Ryan_Lane https://eng.lyft.com/blessing-your-ssh-at-lyft-a1b38f81629d
21:43 lyftbot [caedus41] :thumbsup: Neat!
21:43 lyftbot [caedus41] I've gotta run, but thanks again for all the help!
21:43 Ryan_Lane yw :)
21:53 Ryan_Lane putting some docs and public cluster configs into my roadmap for the quarter (we recently formed a team that has open source as one of its dedicated purposes :) )
22:16 wm-bot joined #confidant
22:22 wm-bot joined #confidant

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