The importance of containers in today’s cloud-native landscape is unparalleled. Ensuring their compliance, especially when you are working in a Federal Risk and Authorization Management Program (FedRAMP) authorized environment, isn’t just a best practice; it is a necessity.
In this post, we will show you how to align your container workflows with FedRAMP requirements without losing speed. We will walk you through practical strategies for achieving FedRamp compliance, from image scanning to policy enforcement and runtime protection
FedRAMP is a U.S. government-wide program that offers a standardized approach to governance assessment by handling security, compliance, authorization, and continuous monitoring. It is based on NIST Special Publications, most notably NIST SP 800-53 for system control and NIST 800-37 for risk management.
While it doesn’t offer container-specific controls, containers are part of the infrastructure and need to comply with the broader security requirements of the FedRAMP-authorized environment. This means that any container operating in FedRAMP environments must respect the policies for access control, audit, vulnerability management, and incident response.
Read more: What is Container Security? 10 Best Practices & Solutions
What is required for FedRAMP compliance?
To achieve FedRAMP compliance in containerized environments, you must meet baseline security controls defined by NIST SP 800-53, along with additional FedRAMP-specific requirements tailored for container technologies.
FedRAMP leverages NIST 800-53 controls to assess the container environment and workloads, while also requiring container hardening based on guidelines such as those in NIST SP 800-70 and benchmarks like the CIS Docker Benchmark.
There are several control areas in which FedRAMP affects container security:
- Access control – ensure proper authentication and authorization of your containers
- Configuration management – manage container configurations securely
- System and information integrity – maintain container image integrity
- Audit and accountability – log and monitor container activity
- Risk assessment – implement regular vulnerability scanning of your containers and images
The following best practices help address key requirements across system integrity, vulnerability management, and continuous monitoring:
1. Secure your container images
To ensure that you start implementing FedRAMP, you should begin with your container images. Whenever you are building a custom image, you should ensure that you start with a minimalist, hardened base image from a trusted source to reduce the attack surface.
In addition, it’s paramount to digitally sign container images to ensure integrity throughout your deployment pipelines. The keys used for signing the images need to be generated so they are secure yet unpredictable, and strict access control policies should be implemented to validate only authorized engineers to handle these keys.
The signing process should be automated within CI/CD pipelines to minimize human interaction, thus minimizing the potential for human errors and breaches.
One of the most important aspects of securing your container images is automating the use of a container image vulnerability scanner. Many tools, such as Trivy, Clair, or Snyk Container, can be used to find vulnerabilities in your container images.
Let’s take a look at a Trivy scan for an image:
trivy image flaviuscdinu93/devops-dev-env:1.0.0
INFO [vuln] Vulnerability scanning is enabled
INFO [secret] Secret scanning is enabled
INFO [secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
INFO [secret] Please see also https://aquasecurity.github.io/trivy/v0.55/docs/scanner/secret#recommendation for faster secret detection
INFO Detected OS family="alpine" version="3.20.2"
INFO [alpine] Detecting vulnerabilities... os_version="3.20" repository="3.20" pkg_num=71
INFO Number of language-specific files num=4
INFO [gobinary] Detecting vulnerabilities...
INFO [python-pkg] Detecting vulnerabilities...
WARN Using severities from other vendors for some vulnerabilities. Read https://aquasecurity.github.io/trivy/v0.55/docs/scanner/vulnerability#severity-selection for details.
In the above scan, you can see that every vulnerability has a code. Copy the code and paste it into a search engine to get more information about how to solve it.
Adding this crucial step to your build pipelines will always keep you up to date with images’ vulnerabilities and hold you accountable for solving them quickly.
2. Policy enforcement
To ensure the safety of your container environment, you will need to use a policy enforcement tool such as Open Policy Agent (OPA) or Kyverno. These tools help you enforce rules around how your containers are built, deployed, and even run. This can reduce the risks associated with misconfigurations or insecure practices.
OPA can be integrated into CI/CD pipelines, APIs, or service meshes. With it, you can enforce policies that deny unsigned images, restrict exposed ports, or validate configuration files.
It can be used both inside and outside Kubernetes, and although it uses a declarative language called Rego that can be hard to learn, it is still useful to do so, as you can easily version your policy configurations.
# Example policy that checks a Docker compose configuration for exposed ports
package main
deny[msg] {
service := input.services[_]
port := service.ports[_]
contains(tostring(port), "22:") or port == "22"
msg := sprintf("Service exposes restricted port 22: %v", [port])
}The above policy can be tested against a Docker compose configuration using ConfTest.
Kyverno is built for Kubernetes, and it allows you to define policies using YAML, enforcing them as part of your Kubernetes admission process. You can enforce your containers to run as non-root, block the usage of the latest tag for images, and many others.
# Example policy that blocks the latest tag
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-latest-tag
spec:
validationFailureAction: enforce
rules:
- name: validate-image-tag
match:
resources:
kinds:
- Pod
validate:
message: "Using ':latest' tag is not allowed. Use a specific image tag instead."
pattern:
spec:
containers:
- image: "!*:latest"Both OPA and Kyverno are great solutions for helping you achieve FedRAMP in container environments.
3. Implement container runtime security
Runtime security ensures that containers behave as expected, suspicious activity is detected, and action is taken as soon as possible.
Tools such as Falco (for monitoring system calls in real time), AppArmor (implements access control in Linux processes), and SecComp (filters the system calls a container can make) are mandatory for implementing container runtime security.
Let’s review an example that detects if an interactive shell is spawned in production containers using Falco:
- rule: Shell in Container
desc: Detect launching of a shell inside a container
condition: >
container
and proc.name in (bash, sh, zsh, ksh)
and not proc.pname in (sshd, kubelet, containerd, dockerd)
output: >
Shell launched inside container (user=%user.name command=%proc.cmdline container=%container.name image=%container.image.repository)
priority: WARNING
tags: [container, shell, security]This rule detects if a shell was spawned in a container and provides details about the user, command, container name, and the container image used. The priority is set to WARNING, but you can easily change it to CRITICAL based on your threat model.
Falco can be easily integrated with Slack, MS Teams, or even Prometheus to ensure that you are alerted about this issue and get the ability to act on the issue as fast as possible.
4. Maintain container isolation
By implementing container isolation, you reduce the blast radius if one of your containers is compromised. Maintaining this isolation in FedRAMP is one of the first stepping stones you need to implement to achieve it.
To maintain container isolation, you can:
- Ensure you are using rootless containers – by running containers as non-root, you reduce host-level risk
- Take advantage of Cgroups (Control Groups) – limit CPU, memory, and I/O operations to prevent neighbor issues and denial of service attacks
- Reduce privilege escalation – map container user IDs to non-root host IDs, and ensure containers don’t share process IDs, network interfaces, or filesystems unless this is explicitly allowed
- Disable inter-container communication by default
- Use read only-filesystems
All of these steps are critical for FedRAMP.
5. Implement continuous monitoring
Security should never be treated as a one-off setup or deemed the sole responsibility of the dedicated security team. Everyone is responsible for implementing security, and continuous monitoring enables ongoing visibility and alerting, making it easy for everyone to spot issues.
In FedRAMP environments, systems should be continuously monitored for compliance, anomaly detection, and incident response. You should monitor the image integrity, container activity, system resources, and ensure you have access logs to detect who did what.
Tools that can be used to implement continuous monitoring include Prometheus + Grafana (for collecting metrics and alerting), Elastic Stack (for centralized logging and search), and Falco (for real-time behavioural monitoring).
See more: 20+ Most Popular DevOps Monitoring Tools
Adopting containers in a FedRAMP environment can create architectural and compliance complexities.
Containers are ephemeral
Containers are short-lived and can scale dynamically, making it hard to track and audit changes in real time. To overcome this problem, you need to implement a container orchestration platform that offers powerful governance features and maintains detailed metadata about your containers.
Supply chain risks
In FedRAMP, you need to know the provenance of all the environment components. To solve this problem in container environments, you need to implement a secure container supply chain with signed images that have verified base layers and a Software Bill of Materials (SBOM) for each container.
Identity and access control
Containers don’t have traditional OS-level user management, which complicates FedRAMP controls. To solve this, you should implement Kubernetes RBAC (if you are using Kubernetes), Kyverno, or OPA to enforce non-root containers, isolate your workloads using network policies, and even integrate with a centralized Identity Access Management (IAM) offering.
Containers change frequently
FedRAMP mandates periodic evidence of control enforcement, but containers change frequently. To address this, you need to automate compliance checks using tools such as Cloud Custodian or OPAN, include security vulnerability scans, and generate automated compliance reports tied to your container events.
If you are looking for an infrastructure orchestration platform to help with your Kubernetes workflows, Spacelift can help. Apart from supporting Kubernetes, it helps you to leverage infrastructure-as-code tools such as Terraform, OpenTofu, and others.
This post explains how Spacelift implements security. To learn more about the product, create a free account today or book a demo with one of our engineers.
Your DevOps/platform engineering practices don’t have to be sacrificed to achieve FedRAMP, but you need to add “Sec” to them. This requires discipline, automation, and visibility, and all the engineering teams involved need to collaborate and treat security as a shared responsibility from code to production.
With the right tools and security postures, your container workflows can be secure, scalable, and fully compliant.
Solve your infrastructure challenges
Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation, and controls to simplify and accelerate the provisioning of cloud-based infrastructures.
