data/aws: Encrypt the AMI used by the bootstrap and master machines #1296
Conversation
openshift-ci-robot
added
do-not-merge/work-in-progress
openshift-ci-robot
added
the
approved
|
/hold |
openshift-ci-robot
added
the
do-not-merge/hold
|
@abhinavdahiya why do we need to wait for a 4.1 branch? this is for 4.0 (exception approved) |
|
We need to do this in Go so that we are using these AMIs for our machine objects. |
feel free to cancel the hold, I was not aware we were merging 4.0 exception approved feature. |
openshift-ci-robot
added
the
needs-rebase
It's not clear to me how this is supposed to work with machine objects, which is why I don't think we need to do this in Go (yet). I expect we'll end up with a machine-API operator that can perform these copy-and-encrypt operations on its own, in which case the configuration would still use the source AMI (which is what we're currently putting there now) with an additional property to request "please use an encrypted copy of this AMI" (which doesn't exist yet). I don't think it's a problem to perform this copy-and-encrypt in Terraform while we work out how in-cluster encrypted AMIs are going to work. Thoughts? |
Why can't the installer create encrypted AMI and set them on machine objects? |
We can, but then we'd need to write |
wking
force-pushed
the
encrypted-master-amis
branch
from
5ada116
to
4964ce8
Compare
openshift-ci-robot
removed
the
needs-rebase
wking
changed the title
openshift-ci-robot
removed
the
do-not-merge/work-in-progress
wking
force-pushed
the
encrypted-master-amis
branch
from
4964ce8
to
f08e266
Compare
openshift-ci-robot
added
size/M
|
I've pushed f08e266 with a rebase onto master and |
|
Can we update docs on AWS regarding the AMI creation and check for AMI limits per account.. ? |
|
Also the openshift-dev account will need to prune these when terminating clusters after 48hrs. |
I don't see a limit on the number of AMIs in an account (although maybe I'm just not looking in the right places?). There is "Destination Regions are limited to 50 concurrent AMI copies", although I'm not sure what that means. Is it a limit on concurrent copy operations or is it a cap on the number of AMIs which were originally created as copies of other AMIs? Is it per-account or across all accounts in a given region? |
|
Also the openshift-dev account will need to prune these when terminating clusters after 48hrs.
At least this. |
This would be addressed by DPP-1066, although I'm sure we can address this via more minor updates to their reaper in the meantime. I'll get something up there within 48 hours of this landing, although I don't expect this to be time-critical, since I can't find a clear AMI limit that leakers would exhaust. |
I don't see a good place for this. Maybe here? With an additional sentence like "This creates an encrypted AMI for the bootstrap and control-plane machines. The encrypted AMI is deregistered by |
wking
force-pushed
the
encrypted-master-amis
branch
from
f08e266
to
4fcef5e
Compare
Added with f08e266 -> 4fcef5e, although as I explain in the commit message, it's not clear to me whether users can configure the default EBS encryption key for the target region if they want to use a custom CMK instead of the Amazon-managed default. We may need to expose |
wking
force-pushed
the
encrypted-master-amis
branch
from
4fcef5e
to
64c5ba8
Compare
|
/hold cancel /lgtm |
openshift-ci-robot
added
lgtm
|
/retest Please review the full test history for this PR and help us cut down flakes. |
This is a quick hack to get encrypted masters. Ideally we'd want to deregister these on bootstrap-teardown, but handling that nicely will be easier after some cleanups from [1]. As it stands, we'll deregister this as part of the general cluster teardown. Because we don't set kms_key_id [2] we get "the default AWS KMS Key" (according to [2]). AWS docs are not particularly clear about whether users can configure the default key for their account/region to override that default, although it is clear that it defaults to an AWS-managed CMK [3] and that the alias for AMI encryption is alias/aws/ebs [4]. If there is no way to override alias/aws/ebs, we'll probably eventially need to expose kms_key_id to users. [1]: openshift#1148 [2]: https://www.terraform.io/docs/providers/aws/r/ami_copy.html#kms_key_id [3]: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [4]: https://aws.amazon.com/blogs/security/how-to-create-a-custom-ami-with-encrypted-amazon-ebs-snapshots-and-share-it-with-other-accounts-and-regions/
wking
force-pushed
the
encrypted-master-amis
branch
from
64c5ba8
to
0c370dd
Compare
|
All green :) |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, wking The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Partially reverts 0c370dd (data/aws: Encrypt the AMI used by the bootstrap and master machines, 2019-02-22, openshift#1296). This isn't a clean revert; for example, I left the ability to destroy images which are tagged as owned by the cluster. And we're still copy-and-encrypting for the bootstrap machine until the AWS Terraform provider supports requesting encrypted root volumes [1]. But with this commit, we no longer use the copied AMI for control-plane nodes, which gets us one step closer to having the cluster API provision them without installer intervention.
Partially reverts 0c370dd (data/aws: Encrypt the AMI used by the bootstrap and master machines, 2019-02-22, openshift#1296). This isn't a clean revert; for example, I left the ability to destroy images which are tagged as owned by the cluster. And we're still copy-and-encrypting for the bootstrap machine until the AWS Terraform provider supports requesting encrypted root volumes [1]. But with this commit, we no longer use the copied AMI for control-plane nodes, which gets us one step closer to having the cluster API provision them without installer intervention. [1]: hashicorp/terraform-provider-aws#8624
Partially reverts 0c370dd (data/aws: Encrypt the AMI used by the bootstrap and master machines, 2019-02-22, openshift#1296). This isn't a clean revert; for example, I left the ability to destroy images which are tagged as owned by the cluster. And we're still copy-and-encrypting for the bootstrap machine and control-plane machines until the AWS Terraform provider supports requesting encrypted root volumes [1]. But with this commit, we're now documenting the encryption in a way that covers both the previous AMI-based encryption used for bootstrap/control-plane and the new root-volume-based encryption used for the compute machines, because they come down to encrypted root volumes regardless of their approach. [1]: hashicorp/terraform-provider-aws#8624
This is a quick hack to get encrypted masters. Ideally we'd want to deregister these on bootstrap-teardown, but handling that nicely will be easier after some cleanups from #1148. As it stands, we'll need to deregister this as part of the general cluster teardown (hence the WIP). CC @ericavonb.