Find a better way to set the SSH deploy key (or don't use one maybe)

[gdestuynder]

Atm it's akrug's key for dev

[andrewkrug]

I'm thinking that once we stabilize this that the workers will be zero-touch. As in "none" for the key.

[andrewkrug]

All of the application logs are going to cloudwatch so we really don't need them. The only reason I could think that I would like a key is in case of DFIR/Forensics. But you can even use CodeDeploy to bootstrap that.

[gdestuynder]

✔ - note @gene1wood has a model/standard for DFIR access, pinging for input

[andrewkrug]

@gene1wood @gdestuynder what do you think about doing a DFIR key per instance.?

Basically I'd add a little snippet to the lifecycle hook to push it into credstash on spin up. github.com/threatresponse/aws_ir has slated to integrate with credstash to retrieve keys

[andrewkrug]

@tristanweir +r on the above idea as a Mozilla standard.

[jeffbryner]

FWIW I like the 'none' plus one for DFIR idea.

[gene1wood]

I was thinking something similar to what @andrewkrug is suggesting

Have hosts generate an ssh keypair on spinup, then gpg encrypt to the opsec key and publish it somewhere

I was going with GPG because it's asymmetric so the instance needs no permissions (including credstash write permissions) and it's a high barrier to get access (opsec GPG key is tightly controlled and not super easy to use).

And until we have

• a standard that says
  • no IAM entity shall have kms:decrypt permissions in a given AWS account
  • all KMS access will be governed through grants
  • all grants must use encryption context to follow principles of least privilege
• an auditor that verifies no IAM resource has been granted kms:decrypt

I'd be a bit wary about putting ssh root keys in credstash

I do think we should get to the point where the risks above are mitigated though.

[andrewkrug]

I'm OK with either of these approaches. Anything is better than just tacking my pub key in there right now.

Though I notably would prefer to create a process that loads to credstash or some secret store as part of the lifecycle hook.

I like the S3 bucket concept as well but would want to discuss tooling around using those keys.

[gdestuynder]

Note, as part of a similar IT break-the-glass system/DFIR we were pondering things such as gpg + sss_share to encrypt secrets. Basically gpg is the trust provider and sss_share allows for shamir secret sharing (for ex: encrypt to 10 ppl and any 3 of them are require to decrypt)

cross ref bug https://bugzilla.mozilla.org/show_bug.cgi?id=1381243

[gdestuynder]

Just ran a test as per above bug and it's pretty decent. The part that I like most is that while it does do quorum based decryption (ie shamir secret sharing), it fully relies on the each user's gpg key to keep their part of the secret, which means no additional key material is needed from users (and gpg is already widely used) The other part I like is that it requires no fancy service thus is very simple to start using (its basically standalone). It also does not matter if KMS is compromised, IAM is compromised, etc.