As there are many serverless Platform-as-a-Service (PaaS) capabilities maturing in the public cloud, enterprises still manage sizable Infrastructure as a Service (IaaS) compute workloads in their cloud ecosystem. Enterprises are faced with challenges to build, maintain, and control many Operating System (OS) distributions, across one or many Amazon Web Services (AWS) accounts.
Announced in a prior blog post, Turbot has simplified OS hardening through Turbot’s Linux OS Guardrails which has elevated many Enterprises to focus less time on engineering OS images, and more time supporting application teams with serverless cloud patterns.
However, with current investments already made, enterprises will often continue building Amazon Machine Images (AMIs) to be published, shared and trusted across their AWS Accounts. When a customer brings their own AMI into AWS, Turbot has many options and guardrails to control where the AMIs are published, and how they are trusted to be provisioned.
Publishing Local AMIs
Turbot supports sharing local AMIs with other accounts and launching AMIs from trusted accounts. These features allow for better management and use of AMIs across your enterprise.
Turbot has guardrails and controls in place to restrict publishing to specific users. When allowing publishing permissions within one or many AWS Accounts, Turbot Administrators can configure the EC2 > Allow AMI Publishing option to Enabled:
If you do not already have an image created, you can either import an existing VM into AWS, or create an image from an existing EC2 instance. The EC2 > Allow Local AMIs option will need to be Enabled to perform either of these actions:
Once your image is available, select your image and edit its permissions, adding in the AWS account IDs you want to publish the image to:
Click Save, and now the list should contain the entered account IDs:
Now that the image is shared with other AWS accounts, we need to allow those accounts to launch instances using that image.
Restricting Specific Shared AMIs
Turbot can help enforce only specific AMIs that are valid for new EC2 provisioning in one or many AWS Accounts through the EC2 > Current AMIs option:
As enterprises refresh their AMIs (e.g. quarterly build) they can deprecate older AMIs through the EC2 > Deprecated AMIs option. Existing instances may use these AMIs, but only new instances can be created from the Current AMI list above:
Allowing Shared AMIs from Trusted Publishers
Enterprises can choose to restrict specific AMIs for finer grain control as mentioned above; however, a simpler configuration would be to allow any AMI to be provisioned from a trusted AMI publisher.
In the Turbot account that the newly created image was shared with, add the image’s owner AWS account ID to the EC2 > Trusted AMI Publishers option (in this example, we’re assuming that the image was created in AWS account 987654321098):
Launching Shared Trusted EC2 AMIs
Now that the AMI is published, shared, and trusted, a user can safely launch that AMI by selecting Shared with me under Ownership. The shared image will appear and can be selected for the new instance:
Complete instance launch configurations as normal and then launch the instance!