Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add kms encryption to eks #12

Merged
merged 6 commits into from
Feb 24, 2022
Merged

feat: Add kms encryption to eks #12

merged 6 commits into from
Feb 24, 2022

Conversation

zythosec
Copy link
Contributor

@zythosec zythosec commented Feb 11, 2022

  • Adds cluster_encryption_config to EKS cluster for cluster secrets
  • Switches out local secret to secretsmanager secret

modules/database/main.tf Outdated Show resolved Hide resolved
@zythosec zythosec changed the title feat: add kms encryption to eks and add mysql secret to secretsmanager feat: Add kms encryption to eks and add mysql secret to secretsmanager Feb 11, 2022
Copy link

@vanpelt vanpelt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, it feels redundant and likely un-necessary to store the database secret in KMS. The secret is in the terraform state, you're taking that secret and storing it in KMS, then you're reading that value from the KMS to put it back into the terraform state 🤔 .

It's eventually going to end up in an environment variable that get's passed to k8s. We should look at the kubernetes module and ensure it's using k8s secrets for the MYSQL env variable. If done properly in the end we would have:

tfstate -> kms -> tfstate -> k8s secrets -> kms -> docker container env 🙃

main.tf Outdated
database_subnet_cidrs = var.network_database_subnet_cidrs
create_elasticache_subnet = var.create_elasticache
elasticache_subnet_cidrs = var.network_elasticache_subnet_cidrs
cidr = var.network_cidr
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did create_elasticache_subnet go away here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bad rebase. Will fix.

variables.tf Outdated
@@ -203,6 +203,12 @@ variable "kubernetes_map_users" {
default = []
}

variable "eks_kms_key_arn" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for consistency we should probably use kubernetes_kms_key_arn

Copy link
Member

@jsbroks jsbroks Feb 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im also confused why we need to pass one in? We already create a kms key. Lets use that, and unless a user requests for the ability to provide one, then we can add it as a variable (i.e, its easier to add options then remove options).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thought when separating this out from the bucket KMS key was to give flexibility to the consumer of the module. If they want to pass in separate keys to encrypt the bucket vs the eks cluster secrets, they have the ability to do so, or they can pass in the same KMS key to both variables.

Copy link
Member

@jsbroks jsbroks Feb 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I would leave it as internal. And default to the internal key. Ethier way if the user doesn't provide a kms_key_arn we should default to the one we create

Comment on lines 27 to 30
resource "aws_secretsmanager_secret_version" "default" {
secret_id = aws_secretsmanager_secret.default.id
secret_string = random_string.master_password.result
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure I see the point in this. We are already storing it in the TF state

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it can be rotated by AWS automatically and not have to be manually managed by the user. Since that involves a separate code change to be able to handle a rotating secret, I've opted to leave it out of this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just the initial version. Eventually, the secret will not be in state because it will have been rotated by AWS.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should leave it out of this PR until the other PR is ready. As you said its involues a seperate code change. That way they can all be reviewed together, and we limit the number of weird cases/one offs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take it out then. The rotation piece that needs to be added is https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/secretsmanager_secret_rotation with the code change for future reference.

@zythosec
Copy link
Contributor Author

@vanpelt

The secret is in the terraform state, you're taking that secret and storing it in KMS, then you're reading that value from the KMS to put it back into the terraform state

There is no way to pass an initial value of a secret to an aws_secretsmanager_secret, you have to create an aws_secretsmanager_secret_version. The reason for this is so we can eventually add rotation to the aws_secretsmanager_secret, which will then discard this initial value.

@jsbroks
Copy link
Member

jsbroks commented Feb 15, 2022

@zythosec Did you run a running to upgrade an existing deployment before these changes? I just want to make sure we arn't introducing any breaking changes? If so Im good to approve

@zythosec zythosec changed the title feat: Add kms encryption to eks and add mysql secret to secretsmanager feat: Add kms encryption to eks Feb 23, 2022
@zythosec
Copy link
Contributor Author

@jsbroks had some initial issues before I had removed all the mysql secret components. Now that only have the EKS/KMS items are in this PR, these changes apply cleanly. Steps I took:

git checkout main
terraform plan -out tfplan
terraform apply tfplan
git checkout kms-eks-secrets
terraform plan -out tfplan
terraform apply tfplan

Tested out signup/login/intro colab/reports and all look good.

@zythosec zythosec merged commit 71774c7 into main Feb 24, 2022
@zythosec zythosec deleted the kms-eks-secrets branch February 24, 2022 19:32
jsbroks pushed a commit that referenced this pull request Feb 24, 2022
## [1.1.0](v1.0.4...v1.1.0) (2022-02-24)

### Features

* Add kms encryption to eks ([#12](#12)) ([71774c7](71774c7))
@jsbroks
Copy link
Member

jsbroks commented Feb 24, 2022

This PR is included in version 1.1.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants