Use Encryption With EBS-backed AMIs (Part 1)

By Ashwin Venugopal -

 





About

Amazon EBS snapshots can be utilized for AMIs that are encrypted. Both root and data volume snapshots can be encrypted and linked to an AMI. You are able to initiate instances and duplicate images with complete support for EBS encryption. The encryption settings for these actions are available in all Regions where AWS KMS is supported.

EC2 instances utilizing encrypted EBS volumes are started from AMIs in the same manner as other instances. Furthermore, when launching an instance from an AMI that is based on unencrypted EBS snapshots, you have the option to encrypt some or all of the volumes at the time of launch. 

Similar to EBS volumes, AMI snapshots can be encrypted using either your default AWS KMS key or a customer-managed key that you designate. In all scenarios, it is essential to have permission to use the chosen KMS key. AMIs that contain encrypted snapshots can be shared across different AWS accounts.

Instance-launching Scenarios

Amazon EC2 instances are initiated from AMIs through the RunInstances action, with parameters provided via block device mapping, either through the AWS Management Console or directly using the Amazon EC2 API or CLI. By default, unless specific encryption parameters are provided, a RunInstances action preserves the existing encryption state of the AMI's source snapshots when restoring EBS volumes from them. 

If default encryption is activated, all volumes generated from the AMI (regardless of whether they come from encrypted or unencrypted snapshots) will be encrypted. If default encryption is not activated, the instance retains the encryption state of the AMI.

You can initiate an instance and at the same time implement a new encryption state on the resulting volumes by providing encryption parameters. As a result, the following behaviors can be seen:

Launch With No Encryption Parameters

  • An unencrypted snapshot is restored to an unencrypted volume, unless encryption by default is enabled, in which case all the newly created volumes will be encrypted.

  • An encrypted snapshot that you own is restored to a volume that is encrypted to the same KMS key.

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

  • The 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:

Instance Launch Behaviors With Encrypted Set, But No KmsKeyId Specified

  • An unencrypted snapshot is restored to an EBS volume that is encrypted by your AWS account's default KMS key.  

  • An encrypted snapshot that you own is restored to an EBS volume 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 restored 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 non-default KMS key for an encryption operation. The following behaviors result:

Instance With Both Encrypted and KmsKeyId Set

  • An unencrypted snapshot is restored to an EBS volume encrypted by the specified KMS key.

  • An encrypted snapshot is restored to an EBS volume 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 

Many instance-launching scenarios about Amazon EBS 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