Use Encryption With EBS-backed AMIs (Part 2)

By Ashwin Venugopal -

 





Encrypt a volume during launch

In below figure, an AMI backed by an unencrypted snapshot is used to launch an EC2 instance with an encrypted EBS volume.

Fig shows: Encrypting a volume during launch-An AMI backed by an... | Download Scientific Diagram

 

The Encrypted parameter by itself leads to the encryption of the volume for this instance. Specifying a KmsKeyId parameter is not mandatory. If a KMS key ID is not provided, the volume will be encrypted using the default KMS key associated with the AWS account. To use a different KMS key that you possess for encrypting the volume, include the KmsKeyId parameter.

Re-encrypt a volume during launch

In the figure below, an AMI backed by an encrypted snapshot is used to launch an EC2 instance with an EBS volume encrypted by a new KMS key.

Use encryption with EBS-backed AMIs - Amazon Elastic Compute Cloud

If you have ownership of the AMI and do not provide any encryption parameters, the resulting instance will have a volume that is encrypted using the same KMS key as the snapshot. In the case where the AMI is shared with you rather than owned by you, and no encryption parameters are provided, the volume will be encrypted using your default KMS key. When specific encryption parameters are given as detailed, the volume will be encrypted using the designated KMS key.

Image-copying scenarios

Amazon EC2 AMIs can be duplicated by utilizing the CopyImage function, either via the AWS Management Console or directly through the Amazon EC2 API or CLI. By default, unless specific encryption parameters are provided, the CopyImage action retains the current encryption status of the source snapshots of an AMI during the copying process. Additionally, you have the option to copy an AMI while also implementing a new encryption status for its related EBS snapshots by including encryption parameters.

Consequently, the following behaviors are observed:

Copy with no encryption parameters

  • An unencrypted snapshot is copied to another unencrypted snapshot, unless encryption by default is enabled, in which case all the newly created snapshots will be encrypted.

  • An encrypted snapshot that you own is copied to a snapshot encrypted with the same KMS key.

  • An encrypted snapshot that you do not own (that is, the AMI is shared with you) is copied to a snapshot that is encrypted by your AWS account's default KMS key.

All of these default behaviors can be overridden by supplying encryption parameters. The available parameters are Encrypted and KmsKeyId. Setting only the Encrypted parameter results in the following:

Copy-image behaviors with Encrypted set, but no KmsKeyId specified

  • An unencrypted snapshot is copied to a snapshot encrypted by the AWS account's default KMS key.

  • An encrypted snapshot is copied to a snapshot encrypted by the same KMS key. (In other words, the Encrypted parameter has no effect.)

  • An encrypted snapshot that you do not own (i.e., the AMI is shared with you) is copied to a volume that is encrypted by your AWS account's default KMS key. (In other words, the Encrypted parameter has no effect.)

Setting both the Encrypted and KmsKeyId parameters allows you to specify a customer managed KMS key for an encryption operation. The following behaviors result:

Copy-image behaviors with both Encrypted and KmsKeyId set

  • An unencrypted snapshot is copied to a snapshot encrypted by the specified KMS key.

  • An encrypted snapshot is copied to a snapshot encrypted not to the original KMS key, but instead to the specified KMS key.

Submitting a KmsKeyId without also setting the Encrypted parameter results in an error.

Conclusion

Some other details about using encryption with EBS-backed AMIs are discussed. 































Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more