-
Notifications
You must be signed in to change notification settings - Fork 19
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
Conversation
zythosec
commented
Feb 11, 2022
•
edited
Loading
edited
- Adds cluster_encryption_config to EKS cluster for cluster secrets
- Switches out local secret to secretsmanager secret
26b1ea5
to
0459168
Compare
0459168
to
cb395a9
Compare
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
modules/database/main.tf
Outdated
resource "aws_secretsmanager_secret_version" "default" { | ||
secret_id = aws_secretsmanager_secret.default.id | ||
secret_string = random_string.master_password.result | ||
} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There is no way to pass an initial value of a secret to an |
@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 |
@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. |
## [1.1.0](v1.0.4...v1.1.0) (2022-02-24) ### Features * Add kms encryption to eks ([#12](#12)) ([71774c7](71774c7))
This PR is included in version 1.1.0 🎉 |