The Anatomy of a EB based Microservice - AWS Security Configuration

Our microservice(s) will be managed by the AWS Elastic Beanstalk Docker service. With Elastic Beanstalk, you can quickly deploy and manage applications in the AWS cloud without worrying about the infrastructure that runs those applications. AWS Elastic Beanstalk reduces management complexity without restricting choice or control.

Nevertheless quite some configuration is still required, which should be standardized in order to allow to automate these steps. One aspect to consider is the Security configuration of your EB instances which are steering the mircoservices.

Standardize the necessary roles and policies from the beginning (amongst other by using a naming scheme) which will help you during the automation of the tasks.

It’s important that you understand the major concepts in context of the AWS Identity and Access Management (IAM capability):

  • IAM Policies, which are documents that formally states on or more permissions. In its most basic sense a policy lets you specify
    • Actions: What actions you will allow of a dedicated AWS service.
    • Resources: Which resources you allow the action on.
    • Effect: What the effect will be when the user requests access - either allow or deny.
  • IAM Identities,which are the identities for which a formally documented policies can be allocated to. An identity can be
    • An IAM user is an entity that you create in AWS. The IAM user represents the person or service who uses the IAM user to interact with AWS.
    • An IAM group is a collection of IAM users. You can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users.
    • An IAM role is very similar to a user, in that it is an identity with permission policies that determine what the identity can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
  • KMS Encryption Key, which is a AWS managed and controlled encryption key provided as part of the AWS Key Management System
  • EC2 Key Pair, which allows you to establish a SSH remote connection to your EB instance.

EB required IAM roles

An EB environment requires two IAM roles for correct functioning. These are
  • EB Service Role
  • EB Instance Profile Role

Service Role

A Service Role grants the EB instance access to use other AWS services on your behalf.

We create a policy which is globally defined and can be integrated in any microservice EB environment.
  • We call it TST.EB.serviceRolePolicy
  • The link, will explain the policy document content
Having done that we create now a Service Role. We decide here to define a role on a microservice level to be flexible for the future.
  • We call it tst.<microserviceName>Service
  • We attach the policy to the role

Instance Profile Role

An Instance Profile Role grants the EB instance permission to call AWS services for features including enhanced health reporting and container management.

We create policy which is which is globally defined and can be integrated in any microservice EB environment.
  • We call it TST.EB.instanceProfilePolicy
  • The link, will explain the policy document content, it will contain policies for
    • Write logs to Amazon Simple Storage Service
    • Coordinate container deployments with Amazon EC2 Container Service in multicontainer Docker environments
    • In worker environments, read from an Amazon Simple Queue Service (Amazon SQS) queue
    • In worker environments, perform leader election with Amazon DynamoDB
    • In worker environments, publish instance health metrics to Amazon CloudWatch
Having done that we create now a Instance Profile Role. We decide here to define a role on a microservice level to be flexible for the future.
  • We call it tst.<microserviceName>
  • We attach the Instance Profile default policy to the role

So now we have defined two roles with the necessary policies, which must be configured to our EB environment template which is used as a configuration for each EB instance.

Each instance created by EB will have this IAM roles allocated and obviously your IAM Roles will have multiple policies attached dependent on your microservice integration into the AWS ecosystem.

Allocate the two roles to your EB environment configuration

The Instance Profile Role will be allocated in the EB Dashboard as part of the “Instances” tab.

The Service Role will be allocated in the EB Dashboard as part of the “Health” tab.

In case you are automating the environment creation process with the help of the AWS Command Line Interface (CLI) you should include the following option settings, which are passed as part of the --option-settings parameter

"Namespace": "aws:autoscaling:launchconfiguration", 
  "OptionName": "IamInstanceProfile", 
  "Value": "tst.curationPlatform" 
"Namespace": "aws:elasticbeanstalk:environment", 
"OptionName": "ServiceRole", 
"Value": „tst.curationPlatformService" 

KMS Encryption Key

Beside the two roles, we will define an Encryption Key provided by the AWS Key Management Service (KMS). The AWS Key Management Service (AWS KMS) is a managed service that makes it easy for you to create and control the encryption keys used to encrypt your data.

Again an Encryption Key is provided per region, where the EB instance will run.

From a naming point of view we will not code the region postfix, due to the fact that you can define the same encryption key on a per region level.

So we will call our key tst_ms_<microserviceName>.

As a key user(s) we assign the role of tst.curationPlatform, i.e. our Elastic Beanstalk Microservice will be able to encrypt and decrypt sensitive data at rest (= in our S3 buckets).

EC2 Key Pair to Enable Remote Login

In order to enable remote login into your Elastic Beanstalk Environment you have to create a EC2 key pair and configure it into your EB configuration.

comments powered by Disqus