Question about AWS KMS keys

[dconneely]

Service name

AWS KMS customer-managed keys

Service environment

(not really applicable at this stage, just a question for now).

• Dev / Development
• Staging
• Prod / Production
• Other

Impact on the service

Provide real impact description on the service mentioned. It can include any potential blockers for the product team.

Not a blocker: We are trying to move away from git-crypt as it is hard to manage changing teams and it seems we should change the underlying data encryption key every time someone leaves - which is difficult.

Submitting this issue as requested in this Slack thread.

Problem description

There are a number of tools, most prominently Mozilla SOPS, which seem to solve the problems we have with git-crypt, but only really solve it if used with an external KMS (like AWS KMS) to wrap the encryption keys so users can be added and removed to the KMS key easily (i.e. using SOPS with PGP or Age keys is not really any better than git-crypt, except that I can set different access to different files in the same repo).

However, I see two issues with the use of SOPS:

1. Cloud Platform, as far as I know, doesn't allow direct creation of AWS KMS keys in a CP Terraform module (some modules create keys indirectly, e.g. S3 or SQS). I might be wrong about this as I know there are a couple of undocumented things (such as Amazon Cognito and Guard Duty on S3 buckets).

2. Even if we could create such a key in TF, and give it attributes so that our AWS Console logins (and presumably other resources tagged with the GithubTeam - e.g. pods?) had permissions to access the KMS key, we could not use SOPS from the command line, as users don't have AWS CLI access on their development machines (only on service pods in the CP).

Are the above assumptions correct? Can I definitively rule out SOPS as a solution?

Contact person

David Conneely, @dconneely (GH), @​David Conneely (Slack), David.Conneely@digital.justice.gov.uk

[mikebell]

Hi,

We don't have a module for KMS keys but we aren't against users using a resource to create the case. We can add in the AWS IAM permissions for our Concourse user if they're not there already.

Have you looked into using secrets manager or ssm as an alternative? We're in the process of looking into removing gitcrypt acrorss CP and this is the route we're investigating at the moment.

[tmahmood72]

Awaiting reply from user @dconneely

[dconneely]

Thanks for getting back. I guess you are saying to use the hashicorp aws module to create a KMS key? I think if that worked, I'd still have the issue that developers can't run AWS CLI to decrypt the encrypted files in the source Git repo (i.e. it would work for CI/CD machines, but not for developers).

SSM parameter store really doesn't seem any different to using AWS Secrets Manager, and at least with Secrets Manager developers can use cloud-platform decode-secret (or kubectl get secret). I'll look into creating a script to get the necessary secrets into a temporary env file before running Docker, or the integration scripts, etc. then auto-deleting the file.

As I say, the ideal would be to version control the secrets alongside the source code (so versions of each could be correlated, tagged, etc.) - obviously using encryption like SOPS (or similar) [but all of these tools are as bad as git-crypt unless you have a remote KMS]. AWS Secrets Manager is a close second.