AWS GovCloud

AWS GovCloud is limited-access regions intended for US Government Agencies and organizations, and related contractors and vendors. Because of its setup and implementation, even information about the deployed instances (for example, IP address space) is considered sensitive, and subject to ITAR regulation. As a result, access is limited to US citizens and approved organizations only.

Because GovCloud is a completely separate AWS instance, it cannot be accessed using your accounts’ normal IAM users, API keys, and secrets. This means that many tools need to be specially configured or implemented to hit the correct API target in order to deploy and manage resources in GovCloud. If your organization is using GovCloud in order to ease the path to securing FedRAMP authorization for your application, be prepared for a lot of duplicative efforts and parallel environments since you cannot commingle non-FedRAMP resources with those inside a FedRAMP system boundary. 

Terraform certainly is in wide use across AWS, including to deploy GovCloud resources. Furthermore, the same reasons for needing an IaC or Terraform manager in standard regions apply to GovCloud use. Because they capture a known state and configuration, the Terraform state and plan files themselves are likely internal to your defined FedRAMP system boundary. However, it is possible to keep the platform that manages the Terraform files themselves outside of your defined system boundary.

There are limitations, though. Because many applications deployed into GovCloud are subject to a variety of security frameworks such as FedRAMP or NIST 800-53, deploying organizations need to be aware of what software must be included in their System Security Plan (SSP). Additionally, best practices of GovCloud deployment mean that GovCloud resources tend to be highly isolated in multiple VPCs with strictly defined security groups.

These deployments have a few impacts:

• GovCloud deployments can be a bit more complex than many standard region deployments in order to meet the stringent Government Security and Compliance requirements. 
• Local execution from a SaaS-connected agent needs to be well understood and implemented to have a minimal impact on the organization's SSP boundary.

Terraform and AWS GovCloud

If you’ve already tried to run Terraform code from AWS commercial, then you likely already know that there are many nuanced differences between AWS GovCloud and commercial cloud implementations. If you have NOT yet attempted to apply your Terraform plans in GovCloud, just know that they’re unlikely to work as written. You will almost certainly need to make updates to your IaC code in order for it to properly create GovCloud infrastructure.

During that porting effort, and once the IaC is complete, env0 with the self-hosted agent is a fantastic way to manage your IaC in GovCloud.

Implementation

The good news is that implementing the env0 Self-Hosted Agent in GovCloud is very similar to other Kubernetes environments. We provide a helm chart that works with AWS EKS in GovCloud. Note that in order to communicate with the env0 SaaS platform, the env0 self-hosted agent for kubernetes needs to have some amount of access to the outside world, so plan your EKS cluster appropriately. Once installed, the agent’s communication abilities can be restricted to a limited number of outbound domains required for the agent to operate correctly. Additionally, limiting the agent’s communication to only the required services, it’s possible to strictly limit what the agent can access.

The Self-Hosted Agent uses EFS to store metadata, terraform plan files, etc. that are required for execution in your environment. While non-sensitive variables are stored within the env0 SaaS system, any sensitive variables and secrets are stored in your selected secrets manager (i.e. AWS Secret Manager, Vault, etc.), which keeps sensitive information inside your SSP boundary and will greatly ease your compliance process.

In order to securely access and run your Terraform code, the Self-Hosted Agent also provides multiple different authentication methods in order to assign an appropriate role to the agent container.

Chances are your organization also already has a defined container image that is the foundation for a number of your container and cloud-native workloads. In GovCloud, as in other environments, it’s not recommended to run container images from unknown or untrusted 3rd parties. The env0 Self-Hosted Agent can use your existing container image.

Implementing the Self-Hosted Agent in this configuration will be compliant with a broad range of frameworks, and withstand your 3rd party assessments and audits as required by FedRAMP and CMMC.

Next steps

Despite a number of our team having lived in the world of compliance, it would be a good idea to consult your compliance readiness firm (if you have one) to more fully understand the impact installing the env0 Self-Hosted Agent in your environment, and to determine the impact from installing an agent to move plan execution internal to your system boundary.

If you’re ready to get started, reach out, and our US-based personnel will be happy to work on an env0 in GovCloud POC with your team.e