18F utilizes the Cloud Foundry Secure Deployment best practices which include the following: Configure UAA clients and users using a standard BOSH manifest for cloud Foundry Deployment. Limit and manage these clients and users as you would any other kind of privileged account. Deploy within a VPC that limits network traffic to individual VMs. This reduces the possibility of unauthorized access to the VMs within your BOSH-managed cloud. Enable HTTPS for applications and SSL database connections to protect sensitive data transmitted to and from applications. Ensure that the jumpbox is secure, along with the load balancer and NAT VM. Encrypt stored files and data within databases to meet data security requirements. Deploy using industry standard encryption and the best practices for your language or framework. Prohibit promiscuous network interfaces on the trusted network. Review and monitor data sharing and security practices with third-party services that you use to provide additional functionality to your application. Store SSH keys securely to prevent disclosure, and promptly replace lost or compromised keys. Use Cloud Foundry’s RBAC model to restrict users’ access to only what is necessary to complete their tasks. Use a strong passphrase for both Cloud Foundry user account and SSH keys.
Store SSH keys securely to prevent disclosure, and promptly replace lost or compromised keys. Use Cloud Foundry’s RBAC model to restrict users’ access to only what is necessary to complete their tasks. Use a strong passphrase for both Cloud Foundry user account and SSH keys.
For further information regarding Cloud Foundry best practices please refer to: https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html https://docs.cloudfoundry.org/concepts/security.html
DevOps maintain baseline configurations for VPC, EBS, EC2 instances and AMIs. AWS Cloud Formation templates help 18F maintain a strict configuration management scheme of the cloud infrastructure. If an error or misconfiguration of the infrastructure or associated security mechanism (security groups, NACLs) is detected, the administrators can analyze the current infrastructure templates; compare with previous versions, and redeploy the configurations to a known and approved state. AWS Cloud Formation templates are the approved baseline for all changes to the infrastructure and simplify provisioning and management on AWS. They provide an automated method to assess the status of an operational infrastructure against an approved baseline. Linux instances are based on the standard AWS AMI images with configuration to GSA requirements based on secure configurations documented in CM-6. DevOps maintain copies of the latest Production Software Baseline, which includes the following elements: Manufacturer, Type, Version number, Software, Databases, and Stats.
Configuration Management Policy for 18F
For AWS Baseline Configurations:
AWS Cloud Formation templates, CIS Level 1 benchmarks and any GSA/18F benchmarks such as hardening guidelines and baselines are the approved baseline for all changes to the infrastructure and simplify provisioning and management on AWS. They provide an automated method to assess the status of an operational infrastructure against an approved baseline.
Windows and Linux instances are based on the standard AWS AMI images in accordance with GSA configuration requirements.
For cloud.gov Baseline Configurations:
cloud.gov utilizes customized Ubuntu stemcells and deployment manifest yaml files for its baseline configurations. The list of the configuration settings can be found at the following site https://docs.cloud.gov/ops/repos/
A stemcell is a versioned Operating System image wrapped with IaaS specific packaging. A typical stemcell contains a bare minimum OS skeleton with a few common utilities pre-installed, a BOSH Agent, and a few configuration files to securely configure the OS by default. With AWS, official stemcells are published as AMIs that can be used in the 18F AWS account. Stemcells do not contain any specific information about any software that will be installed once that stemcell becomes a specialized machine in the cluster; nor do they contain any sensitive information which would make them unable to be shared with other BOSH users. The deployment manifest is a YAML file that defines the components and properties of the deployment.
Note: Additional OS/Device-specific industry standards and guidance may also be used whenever appropriate. It is understood that when industry standards are adopted they may need to be adapted for the specific implementation and if/where this has occurred it should be mentioned/referenced. 18F ensures that the most current, relevant OS/Device-specific industry standards and guidance is maintained where appropriate to support cloud.gov configurations. These best practice updates are captured during the annual review of the CM Policy which also incorporates 18 procedures.