Container Encryption: FIPS Validated and compliant encryption for cloud native workloads

Session Overview

• Requirements for FIPS validated data-in-transit encryption for containerized workloads.
• Challenges for implementing data-in-transit encryption for containerized workloads.
• What AWS, GCP, and Azure provide to assist with this challenge.
• Proposed options to address remaining FedRAMP cloud service provider responsibilities for data in-transit encryption.

Download Full Presentation (PDF)

What the FedRAMP Baseline Says

The cloud service provider must protect the integrity and confidentiality of transmitted information. The method for protecting the confidentiality of transmitted information is through encryption. Where encryption occurs, Federal Information Processing Standards (FIPS) validated or National Security Agency (NSA) approved cryptography must be used. Encryption for data-at-rest and data-in-transit is a federal mandate. When leveraging encryption from underlying FedRAMP authorized IaaS/PaaS providers, CSPs must understand their responsibility for encryption.

How This Applies to Containers

From SC-8, Additional FedRAMP Requirements and Guidance, this control applies to all data in transit. Examples include data flows:

• Crossing the system boundary
• Between compute instances - including containers
• From a compute instance to storage
• Replication between availability zones
• Transmission of backups to storage
• From a load balancer to a compute instance
• Flows from management tools required for their work - e.g., log collection, scanning, etc.

FedRAMP considers any data in transit, whether that be from one container to another container, from a container to a sidecar inside the same host virtual machine, or from a container to any other source outside that container, that SC-8 controls must be applied to this data in transit. SC-8 protection (usually encryption) is required when data is in transit from one memory processing space to another.

Recent Clarifying FedRAMP Guidance and Insights

Container to container data-in-transit encryption includes:

• From container to container - including on the same host (worker node)
• From container to container - including within the same pod where more than one containers exists within a pod*
• From container to sidecar - including on the same host*
• From container to any other source outside the container
• Data in transit from one memory processing space to another*

FIPS encryption can be challenging

FIPS by itself isn't easy, and it can lead to many application-level concerns. As a prospective seller to the US Government, you must ensure that your control plane, your images, and your data in transit are fully FIPS compliant using FIPS validated modules. Meeting FIPS isn't easy when you do it yourself, thankfully Cloud Providers like AWS, Azure, and GCP do take some (not all) of the load off. There are other technologies or approaches beyond what underlying IaaS/PaaS providers offer that can bridge the gap to full compliance.

What to Know Relative to These Requirements

What can be inherited from the IaaS/PaaS provider? Inheritance from AWS, GCP, and Azure for EKS, GKE, and AKS respectively.

After the IaaS/PaaS provider, what remaining customer responsibility exists?

• Container network intra-node, intra-cluster, intra-pod
• Cluster node configuration where applicable
• Container network traffic coming into services within the cluster and leaving the cluster

What options exist to facilitate meeting the remaining customer responsibilities?

• Chainguard - FIPS at the container
• ServiceMesh - FIPS for overlay network on which containers reside
• Refactor Application - Refactoring application architecture to account for FIPS encryption requirements for data-at-rest, data-in-transit, other cryptographic functions.

What Can Be Inherited from Amazon Web Services

EKS responsibilities - What AWS manages for you:

• You receive a control plane managed by AWS.
• Automated etcd backups of all your configurations.
• Management endpoints capable of FIPS.
• High availability options can be managed through ASGs.

EKS responsibilities - What AWS doesn't do for you:

• Node images don't come with FIPS out of the box.
• Node images don't come with CIS/STIG hardening out of the box.
• Encryption in transit is on you.
• You can leverage KMS to encrypt root EBS volumes and other data stores.
• IAM role mappings are on you to manage.

What Can Be Inherited from Google Cloud Platform

GKE responsibilities - What Google manages for you:

• You receive a control plane managed by Google.
• Automated etcd backups of all your configurations.
• Management endpoints capable of FIPS.
• High availability options can be managed through managed node groups.
• GKE claims full responsibility for nodes (cos_containerd, recommended).
• GKE provides inheritable encryption for data in transit between nodes and between control plane and nodes.

GKE responsibilities - What Google doesn't do for you:

• Encryption in transit is on you.
• Cluster nodes cannot be configured for FIPS; Google performs encryption with the underlying network.
• Cluster role mappings are on you to maintain.

What Can Be Inherited from Azure

AKS responsibilities - What Microsoft manages for you:

• You receive a control plane managed by Microsoft.
• Automated etcd backups of all your configurations.
• Management endpoints capable of FIPS.

AKS responsibilities - What Microsoft doesn't do for you:

• Node images don't come with FIPS out of the box.
• Node images don't come with CIS/STIG hardening out of the box.
• Encryption in transit is on you.
• You can leverage Cloud Native encryption to encrypt root volumes and other data stores.
• User permission mappings are on you to manage.

Solutions for What Remains

Chainguard for Solving for FIPS

What is Chainguard? Base containers to save your day!

• A solution starting at the image level.
• You don't need to roll your own encryption solution into your applications.
• A claimed "0 CVE Environment."
• Built-in Image Signing to meet further requirements of development.
• Base encryption leveraged from OpenSSL 3.0.8 for FIPS 140-2.
• Active development of OpenSSL 3.1 bases for FIPS 140-3.

How Chainguard may fall short:

• A FIPS Compliant base image might not mean all encryption in transit is truly FIPS.
• What if your base runtime is missing?
• Migrating your base containers can be a headache!
• Unless you're adopting Chainguard everywhere this can cause development divergence.

Service Mesh: What, Why, How

What are our Service Mesh Options? Anthos (GCP), AppMesh (AWS), Istio for AKS (Azure), Buoyant, Tetrate. These options are common pattern solutions seen by Coalfire for ATO and the "Native" solutions provided by our Big Three of Cloud.

Why it qualifies:

• As of time of writing FIPS remains our biggest challenge for all things FedRAMP. It probably always will be!
• Sidecar based mTLS encryption is leveraged with FIPS validated cryptography.
• Meaning that all of your inter-node encryption will meet Federal mandates!

How to adopt this approach:

• If you are already using LinkerD or Istio, this is a great time to consider Buoyant or Tetrate for responsibility offload.
• If you need to ensure FIPS in your Kubernetes application and you don't know where to start, a service mesh may be the easiest way to batten down the hatches.

Service Mesh: Why Not

• Service Mesh has recently been brought into question as a result of March 16 2024 FedRAMP guidance.
• Implementation is the name of the game.
• Consider if you leverage the other uses of a Service Mesh:
  • Service Discovery
  • Load Balancing
  • Traffic Management & Splitting
  • Request Mirroring
  • Monitoring
  • Security – FIPS mTLS
• If you are already using a service mesh, this is a great approach forward. If you need a fast path to FIPS mTLS, a service mesh might be right for you!

Refactor Applications for FIPS

What this means:

• You can do it all, but that's an uphill battle.
• This means building your images on your own FIPS base image.
• This means ensuring your network exposed services leverage FIPS 140-2/140-3.

Why it qualifies:

• If you're building it yourself, you can ensure FIPS is everywhere!
• You can ensure that services only employ FIPS encryption to communicate.
• You maintain full control of your software development processes and images from the ground up!

Challenges with this option:

• Maintaining this approach with consistency.
• Higher development effort.
• Development pipelines checking for FIPS.

Why it may fall short:

• Vendor supplied container images that are not alterable.

Other Considerations:

• Providing evidence that applications is using proper cryptographic libraries and providers for application-initiated data-in-transit communications.