Add KMS key creation and conditional policy for SNS + Other Services #49
Conversation
|
ghost
self-requested a review
kristianiliev1
changed the title
kristianiliev1
requested review from
mihailradkov
and removed request for
viktor-ribchev
kristianiliev1
force-pushed
the
GDB-9961-KMS-CMK
branch
from
fc50972 to
d043166
Compare
| default = "KMS Key to encrypt SNS" | ||
| } | ||
|
|
||
| variable "key_spec" { |
variables.tf
Outdated
| # KMS CMK | ||
|
|
||
| variable "enable_cmk" { | ||
| description = "Enable CMK for encryption. If false, use AWS managed key." |
There was a problem hiding this comment.
I would expand the CMK abbreviation in the description.
variables.tf
Outdated
| # KMS CMK | ||
|
|
||
| variable "enable_cmk" { | ||
| description = "Enable CMK for encryption. If false, use AWS managed key." |
variables.tf
Outdated
| default = false | ||
| } | ||
|
|
||
| variable "kms_master_key_id" { |
There was a problem hiding this comment.
I don't see this used anywhere in the monitoring module, do we support passing existing keys or not?
variables.tf
Outdated
| default = "" | ||
| } | ||
|
|
||
| variable "sns_cmk_policy" { |
There was a problem hiding this comment.
Another variable that I think is not even used.
There was a problem hiding this comment.
Perhaps I've been testing something. Thanks for noticing...
modules/monitoring/cmk.tf
Outdated
| "Effect" : "Allow", | ||
| "Principal" : { | ||
| # Use 'var.sns_key_admin_arn' if available and root if not provided | ||
| "AWS" : var.sns_key_admin_arn != "" ? var.sns_key_admin_arn : "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" |
There was a problem hiding this comment.
@simeonzhekofff, is root okey here? I'm not familiar with the requirements.
There was a problem hiding this comment.
This parameter defines who is the principal of the key, It shouldn't be root. It's better to be a group for example KeyAdmins or something like that.
| } | ||
|
|
||
| variable "key_spec" { | ||
| description = "Specification of the Key." |
There was a problem hiding this comment.
This description doesn't give me info why it's needed and what's the use of it.
| @@ -5,7 +5,7 @@ | |||
| resource "aws_sns_topic" "graphdb_route53_sns_topic" { | |||
| provider = aws.useast1 | |||
| name = "${var.resource_name_prefix}-route53-sns-notifications" | |||
| kms_master_key_id = "alias/aws/sns" | |||
| kms_master_key_id = var.sns_external_kms_key != "" ? var.sns_external_kms_key : (var.enable_sns_kms_key ? aws_kms_key.sns_cmk[0].arn : var.sns_default_kms_key) | |||
There was a problem hiding this comment.
I don't think that you need an additional variable for the default KMS key variable. Instead, use:
kms_master_key_id = var.sns_external_kms_key != "" ? var.sns_external_kms_key : (var.enable_sns_kms_key ? aws_kms_key.sns_cmk[0].arn : "alias/aws/sns")
| "Sid" : "Allow root user to manage key", | ||
| "Effect" : "Allow", | ||
| "Principal" : { | ||
| "AWS" : "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" |
There was a problem hiding this comment.
Doesn't that work without specifying root?
There was a problem hiding this comment.
No, the idea is that the Root account have access so if anything goes wrong like it did in the other account, that the root account can fix it.
There was a problem hiding this comment.
This doesn't look like a good approach. Imagine deploying this in your department AWS account, something goes wrong and you need to request support from the root account holder. This could be incredibly slow and tedious procedure in some companies.
There was a problem hiding this comment.
I agree, however we have had a problem last week with a Key that was created without a policy for some reason and it could not be reached, opened or deleted. That's why I have added this "safety net" just in case. It is only for the root account. I could remove it if you think it is bad, I don't think it will affect the rest of the module, however I have only put it in case it goes wrong agian.
There was a problem hiding this comment.
I was rather going in another direction, can't se allow only people with admin roles to access it.
There was a problem hiding this comment.
Okay, I'll research for another solution, test it and come back to you.
There was a problem hiding this comment.
Since there isn't a default admin group/role that we can use, I can create it so that they can (if they want) provide admin group's ARN which will get the full access over the keys and if not provided it will be left empty.
There was a problem hiding this comment.
I don't see other options here @simeonzhekofff WDYT?
There was a problem hiding this comment.
We can have an admin group that should have the right to assume an IAM role that has permission to take actions on the key.
ghost
closed this
Description
Added KMS Key creation. Added policy for it. Added a variable - if set, will create CMK key, if not - will use AWS default keys.
Related Issues
https://ontotext.atlassian.net/browse/GDB-9961
Changes
Screenshots (if applicable)
Checklist