Perl 6 - the future is here, just unevenly distributed

IRC log for #confidant, 2016-10-04

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

All times shown according to UTC.

Time Nick Message
01:22 RandyT joined #confidant
20:36 agy joined #confidant
20:36 agy left #confidant
20:37 yann1 joined #confidant
21:06 yann1 joined #confidant
22:01 yann1 Hey there,
22:01 yann1 I came across Confidant while looking for a secure credential storage service, and really liked the concepts: specifically how it uses AWS KMS & IAM to authenticate the different services.
22:01 yann1 However, diving a little more into it, I realized that this mechanism could also make instance revocation (blacklisting) access to a service difficult (impossible?).
22:01 yann1 For instance, let's consider the scenario where an EC2 instance is suspected to be comprised. One may want to prevent it from accessing any credential. To do it, one can:
22:01 yann1 1. Kill the instance (for lack of being able to remove the IAM role of a running instance)
22:01 yann1 2. Remove the entire role from the service in Confidant. Downside: this would impact other instances as well :/
22:01 yann1 3. Do anything else?
22:01 yann1 I am not satisfied by 1 nor 2. Confidant does not seem to provide a solution either.
22:01 yann1 Is this a scenario that you considered? If so, would you have any advices? Thanks!
22:44 yann1 left #confidant
23:12 lyftbot [russmac] You can remove the IAM role on a running instance.
23:12 lyftbot [russmac] The profile is just a container. You can swap them out as you see fit.
23:13 lyftbot [russmac] that being said all other instance profiles with that role now have no role also.
23:13 lyftbot [russmac] or the one you replace it with.
23:14 lyftbot [russmac] You would need in a en env/stack/tier model,  one service per tier which should only have one instance in it.
23:14 lyftbot [russmac] Therefor, You could do anything you liked.
23:15 lyftbot [russmac] so removing prod-website-web , Should only effect that and other ASG instances like it. Your solution is more granularity,  Any alternative mechanism/software would require similar granularity to function in such a way even if it wasn't obvious in its use.
23:18 lyftbot [russmac] Alternatively you could use credentials to assume a role (confidant service), without that granularity of confidant service but with the user credentials granular per instance
23:18 lyftbot [russmac] Revoke the creds for the instance that assumes that role/confidant service
23:19 lyftbot [russmac] IMHO anyway, I'm not an expert.
23:22 woodrow yann1 seems to be gone, unfortunately
23:22 woodrow but this is a limitation of the way that kmsauth (the protocol that confidant uses to authenticate instances) works
23:23 lyftbot [russmac] Oh, Right hes on IRC not gitter.
23:23 lyftbot [russmac] He can still scroll up when he gets back I guess.
23:23 woodrow if you have valid STS credentials, you can generate a kmsauth token
23:23 lyftbot [russmac] I mentioned that.
23:24 woodrow so he is correct that you can't easily revoke a single instance's ability to access secrets in confidant
23:25 lyftbot [russmac] If the service is granular per instance you can, If you assume a rolw as a user with multiple credentials you can.
23:26 woodrow sure, but if you have multiple instances in an autoscale group, you can't only block one right?
23:26 lyftbot [russmac] Yup I mentioned that.
23:26 woodrow if that's a requirement, you probably need a different auth mechanism, or you need to drop/change security group rules to limit network connectivity from that instance to the confidant service
23:30 lyftbot [russmac] I'd definitely be nuking AMI/entire ASG if one was compromised. Especially if the intrusion attempts/success had been load balanced. I dont see the use case.
23:33 woodrow yeah, presumably you'd want to unmap the entire IAM role from confidant
23:33 woodrow which could be an interesting feature
23:34 woodrow like "pause this IAM role"
23:34 lyftbot [russmac] never heard of a launch config regenning private keys per instance either.
23:34 lyftbot [russmac] aws iam revoke-grant ...
23:34 woodrow what do you mean?
23:34 lyftbot [russmac] You'd have to click update grants to restore wouldn't you?
23:35 lyftbot [russmac] Well if an instance in an ASG is compromised, presumably they share an AMI and private ssh keys. So all traffic is now intercept-able between them.
23:37 woodrow oh, i was thinking you'd have confidant stop sending credentials to certain IAM roles to accomplish this goal of incident response to a potentially-compromised asg
23:38 woodrow not sure i follow with the key compromise concern, but i suppose it depends on what you're distributing with confidant and whether you store it on instance filesystems
23:39 lyftbot [russmac] Either way I think @Yann should give it a go, I think he can mitigiate his concerns through his choice of configuration :).
23:40 lyftbot [russmac] The more the merrier.
23:49 woodrow so russmac, you're a confidant user?

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