AWS Authorization Process
This topic describes the AWS authorization process in depth.
To fully understand the description that follows, first familiarize yourself with some key AWS terminology:
IAM (Identity and Access Management): Enables you to manage access to AWS services and resources securely. Using IAM, you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.
CloudFormation: Provides a common language for you to describe and provision all the infrastructure resources in your cloud environment. CloudFormation allows you to use a simple text file to model and provision all the resources needed for your applications across all regions and accounts - in an automated and secure manner. This file serves as the "single source of truth" for your cloud environment.
KMS (Key Management Service): A managed service that makes it easy for you to create and control the encryption keys used to encrypt your data, and uses FIPS 140-2 validated hardware security modules to protect the security of your keys.
Roles: A role is similar to a user in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources.
Cross-account access: A method of granting permission to one AWS account to gain access to a specific role in your account. This AWS blog post provides a guide on how to set up the cross account access. Note that MissingLink does this as part of the
VPC (Virtual Private Cloud): Lets you provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define.
As part of the Authorization process MissingLink installs the following:
- VPC: By default, all instances launched by MissingLink are launched in a separate VPC that is created as part of the authorization. The VPC also sets up additional needed entities, such as security groups, routing tables, and others.
- S3 bucket: If you have not used DataVolume before, MissingLink creates and configures a new S3 bucket for you. This bucket will be used for a data volume dedicated to artifact management. You can create additional data volumes in the bucket using the MissingLink dashboard or the MissingLink CLI commands.
Two roles: MissingLink uses two different roles:
- One role is a cross-account role that allows MissingLink to manage EC2 instances in your account, so that we can create and remove EC2s that are required to fulfil your resource management queue.
- The other role is assigned to machines that MissingLink launches. It has read/write permissions to your s3 buckets that host data volumes.
The buckets are only configured during the initialization of the AWS authorization. If you add new buckets and want to be able to access them from instances that are launched by MissingLink, you will need to grant access to the EC2 role that was created by MissingLink.
KMS key: This is a key used for encrypting your SSH key. As part of the
aws initcommand, the role used by the EC2 instances is granted
decryptpermission. This allows instances inside your cloud to decrypt your organization encryption key securely without granting MissingLink access to any of those keys.
While the authorization utilizes different services in your account, all the resources that are created rely on three cloud stacks:
- The AUTH stack containing the roles, permissions and KMS key.
- The VPC stack containing the VPC, security groups, routing tables, and so on.
- The S3 stack containing the bucket and permissions for the S3 functionality.
By going over the resources registered in the cloud stacks you can see all the changes MissingLink made in the cloud account. Furthermore, if you would like to revoke or modify MissingLink’s access to your account, you can simply delete or modify the cloud stacks.
When removing the stacks, S3 buckets created by MissingLink will not be deleted as they may contain data that you need. You can always remove the bucket manually. In addition, KMS encryption keys are not deleted immediately; instead they are marked for deletion and automatically removed after 30 days by AWS.
Even though buckets and KMS keys are not removed immediately, permissions defined in the cloud stacks are revoked.