Infrastructure Best Practices#

Bixal utilizes infrastructure as code (IaC) for services that support it. IaC provides reproducibility and allows for ephemeral environments. Different technologies exists to accomplish this task from Terraform, Ansible, Chef, Puppet, or SaltStack are common technologies that we've run across.

To document all the best practices of each different technology you encounter is out of the scope of this document. The goal of this page is to cover the major security concerns and serve as an introduction how to build and maintain infrastructure.


What is FedRAMP#

FedRAMP is an program authorized by the OMB to streamline the 'Authority to Operate' process and simplify setting up technology systems and fulfilling FISMA requirements. It's very verbose with some 800+ controls related to the security and procedures around ownership of technology at the federal level. To sum up what it addresses:

FedRAMP lets us use a platform like Acquia, and not have to be responsible for the physical hardware and only be responsible for the application and user management.

Network Architecture#

Projects should always take network architecture into account when designing servers and infrastructure. All Cloud Service Providers (CSP's) have the ability to create public, and private subnet's. By utilizing this architecture services can remain private and more protected, and services such as bastion hosts may be used to harden access to private services. For more information on this type of architecture you can review AWS's reference documentation. While this documentation is AWS specific, the concepts apply across CSP's.

Amazon Web Services#

Currently Bixal utilizes AWS with it's cloud hosting provider.

IAM and Role Based Access#

All CSP's, which have a fedRAMP authorization have have strong identity and role based management. It is imperative that teams follow a policy of least privilege and never simply grant full access to a service. These controls, along with use of multi factor authentication are of the highest priority when dealing access to environments. Credentials should NEVER be shared all of the following services will allow for unique identifiers and credentials to be created for users and services.

Accessing Cross-Account Roles#

Generally access is given to a role by using AWS Security Token Service. You will have a user which has been given a policy to assume a role. In order to be able to assume a role, you must have multi-factor authentication set up. This only works with the Virtual device MFA, not with Yubikey U2F, in the CLI. Both Virtual devices and U2F can be used in the console.

Once you have a user account, with MFA and password setup you can create an access key or use the one provided to you.


In order to assume a role in the AWS console that exists on an account that is not the one that you have a user on, do the following:

  1. Open the link given to you with your user credentials.
  2. Use the provided username and password to sign in.
  3. In the upper right corner, next to the bell, click on your username.
  4. Then click on "Switch Role", then "Switch Role" again at the following screen.
  5. Enter the account number and role name provided in the role ARN. More details here.
  6. Click "Switch Role" again. You will be redirected to the account your role is on.
Assign MFA for yourself by:#
  1. Clicking on your username next to the Bell icon in the top right bar
  2. Clicking on "My Security Credentials"
  3. "Manage MFA device" and add your preferred device
  4. Sign out of AWS and back in using your MFA device


Once you have an access key you can install the aws cli. To configure the aws cli with a main sign on and cross account role with mfa, create a ~/.aws/credentials file. This file should look something like this:

aws_access_key_id = MYACCESSKEY
aws_secret_access_key = MYSECRETACCESSKEY
role_arn = arn:aws:iam::9999999999:role/developer-role
source_profile = default
mfa_serial = arn:aws:iam::111111111:mfa/my-username
region = us-east-1

Here is what you will need to <change> from the example:

aws_access_key_id = <change>
aws_secret_access_key = <change>
role_arn = arn:aws:iam::<change>:role/<change>
source_profile = default
mfa_serial = arn:aws:iam::<change>:mfa/<change>
region = <change if needed>

To access resources under this assumed role:

aws --profile projectname <awscli subcommand>

For example, to list the S3 buckets in myCoolProject:

aws --profile myCoolProjectProfileName s3 ls

where myCoolProjectProfileName is the name of the block similar to projectname above.

If you prefer to not use the --profile command option you may:

export AWS_PROFILE=myCoolProjectProfileName
aws s3 ls

and aws s3 ls will be executed using the profile that you just exported.

For each of these command examples, you will be prompted for your Virtual MFA device's 6 digit code. You will not be prompted for this again unless you change terminals or your role expires. In either case, supplying the new code will allow you to assume the role again.

Role ARN Breakdown#

When you are granted access to a role that allows cross-account access the ARN will look like this: arn:aws:iam::000000000000:role/role-name. This includes two parts that are important for assuming that role through the console:

  1. Account number: 000000000000
  2. Role name: role-name

Gov Cloud vs Public Regions#

The primary differences between Gov Cloud and a General Public regions is staffing, and availability of services and FedRAMP authorizations. Gov Cloud has FedRAMP high along with some related DoD impact level certifications. It achieves this by staffing only US Citizens and a reduction in overall services where they cannot be compliant to the standard.

What this means as an architecture perspective is the following:

Edit on GitHub

Documentation built with MkDocs using a modified Windmill Dark theme