FedRAMP and Kubernetes: Container Orchestration Authorization

The Kubernetes orchestration platform is a deployment substrate for cloud-native SaaS. The Federal Risk and Authorization Management Program (FedRAMP) describes containers as elastic and sometimes ephemeral. Containers can be elastic and ephemeral, replaced rather than upgraded, and container traffic creates paths the assessor must account for.

That elastic operating model must fit a FedRAMP boundary that accounts for every system component and traffic path. The fit determines whether a Kubernetes-based product can hold an Authority to Operate (ATO).

The orchestration tools, registry, image classes, and deployment pipeline inside the boundary become assessed components. An accurate boundary clarifies compliance responsibilities and supports a predictable certification schedule for federal sales.

Key Takeaways

• Boundary includes orchestration. FedRAMP requires the tooling that builds, tests, and deploys containers to be validated by a FedRAMP-recognized independent assessment service (formerly called a Third-Party Assessment Organization, or 3PAO) against CA-2, CM-2, CM-3, SC-28, SI-3, and SI-7; non-hardened images may not run inside it.  
• Controls map directly. Role-Based Access Control (RBAC) covers AC-2(7), AC-3(7), and AC-6; Pod Security Admission (PSA) caps privilege at admission; Kubernetes NetworkPolicy controls implement SC-7 for east-west traffic.  
• FIPS protects cluster traffic. Federal Information Processing Standard (FIPS) 140-3 is the target for new implementations; the FIPS 140-2 transition ended September 21, 2026, when remaining 140-2 certificates moved to the historical list. Sidecar-based mutual Transport Layer Security (mTLS) can protect pod-to-pod paths without application changes; etcd encryption at rest is a separate SC-28 obligation.  
• Ephemeral workloads require automation. The 30-day scanning window starts when an image reaches the production registry, and inventory, registry monitoring, and audit logging must refresh without manual work.

Kubernetes Reframes How FedRAMP Defines the Boundary

Kubernetes is an open-source container orchestration platform that automates deploying, scaling, and managing containerized applications across clusters of hosts. It schedules workloads onto nodes, restarts failed containers, and reconciles the running environment against a declared desired state.

That automation model reshapes what falls inside a FedRAMP boundary. Under Office of Management and Budget (OMB) Circular A-130, the boundary covers every approved component, which for a Kubernetes-based system includes:

• management and orchestration;  
• privileged security tooling;  
• authentication systems;  
• keying material and secrets; and  
• for containerized systems, the production registry, image classes, and deployment pipeline, which also require documented controls.

FedRAMP’s Vulnerability Scanning Requirements for Containers require an independent assessor to validate those orchestration tools against CA-2, CM-2, CM-3, SC-28, SI-3, and SI-7, and to block containers that fail FedRAMP checks. Development and test stages left of the production registry may sit outside the boundary; the registry and everything downstream sit inside it.

Control inheritance applies when the system is hosted on a FedRAMP-certified Infrastructure as a Service (IaaS) or Platform as a Service (PaaS); without a certified underlying offering, it cannot inherit controls.

FedRAMP Request for Comments 0005 (RFC-0005) “rescinds and replaces ALL previous guidance related to the boundaries of all FedRAMP authorizations and certifications,” and the optional Minimum Assessment Scope path available since January 12, 2026 lets providers define the assessed scope narrowly enough to exclude components that do not affect the offering’s security.

Once you define the boundary, Kubernetes access controls determine how privileges and traffic are constrained within it.

RBAC, Pod Security, and Network Policy Satisfy FedRAMP Access Control Requirements

Four Kubernetes mechanisms carry most of the in-cluster access control burden under the National Institute of Standards and Technology (NIST) framework, including NIST SP 800-53 Rev5.

1. RBAC Enforces Least-Privilege Access Across the Cluster

Role-Based Access Control (RBAC) is the Kubernetes authorization model that regulates access to cluster resources based on the roles assigned to individual users or service accounts.

Kubernetes RoleBinding behavior binds named Roles to subjects through RoleBindings, the role-based policy AC-3(7) calls for; deleting a binding is the revocation AC-2(7) requires. Least-privilege guidance limits users and processes to the specific actions and resources their roles require.

A dedicated ServiceAccount per workload and namespace-scoped Roles are preferable to ClusterRoles, since Kubernetes assigns the default ServiceAccount to any pod that doesn’t specify one.

2. PSA Blocks Privileged Pods Before They Run

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that evaluates pods against the Pod Security Standards at creation time and rejects those that violate the configured profile.

PodSecurityPolicy was deprecated in v1.21 and removed in v1.25 when Pod Security Admission became stable. The Restricted security profile requires allowPrivilegeEscalation: false and a seccomp profile of RuntimeDefault or Localhost, and refuses violating pods before they run, an AC-3 decision that also caps privilege per AC-6.

Images must be hardened to National Checklist Program benchmarks, because “Non-hardened or general-purpose images may not be used within the authorization boundary.”

3. NetworkPolicy Delivers SC-7 Separation for East-West Traffic

NetworkPolicy is a Kubernetes resource that specifies how pods can communicate with each other and with other network endpoints at the IP address and port level.

Without namespace network policies, all pod ingress and egress is allowed. A default-deny-all policy that selects every pod, followed by explicit allow rules, delivers SC-7 separation between publicly accessible components and internal networks at the pod and namespace level.

4. Secrets Belong Outside the Default Etcd Store

Kubernetes Secrets store sensitive data such as passwords, OAuth tokens, and SSH keys, decoupling that data from pod definitions and container images. By default, Kubernetes stores secrets unencrypted in etcd, and anyone who can create a pod in a namespace can read any Secret in it.

Encryption at rest, least-privilege RBAC gating, and volume mounts are recommended mitigations because Secrets in environment variables can leak through logs and crash dumps. An external secret store combined with those protections supports stronger secret access and at-rest guarantees.

Traffic between containers requires separation by sensitivity and policy, even after a policy allows it.

FIPS 140-3 Encryption Protects Data in Transit Inside Kubernetes Clusters

FedRAMP’s FIPS cryptography requirements call for FIPS 140-3 wherever cryptography protects federal data. The FIPS 140-2 transition ended September 21, 2026, when remaining 140-2 certificates moved to the historical list, and new implementations should use FIPS 140-3.

The FedRAMP cryptographic module policy bars cloud service providers (CSPs) from calling modules “FIPS compliant,” a term the Cryptographic Module Validation Program does not certify. Kubernetes multiplies the paths SC-8 governs, as described in NIST SP 800-190:

• Pod to pod.  
• Pod to API server.  
• Kubelet and etcd connections.  
• Container to sidecar on the same host.

Each path requires cryptographic protection when it carries federal data.

A service mesh can apply sidecar-based mTLS across pod paths without requiring per-service application changes. Traffic-protection cryptographic modules must still meet FedRAMP’s validation policy.

Data at rest is a separate obligation: kube-apiserver encryption configuration encrypts Secrets before they reach etcd, as SC-28 requires.

Container Images Carry Monthly Scanning Obligations and Deviation Evidence Requirements

These requirements supplement FedRAMP’s vulnerability scanning rules for any system running containers.

1. Every Image Class Scans on a 30-Day Cycle

“The 30-day scanning window begins as soon as the container is deployed to the production registry. Only containers from images that have been scanned within a 30-day vulnerability scanning window can be actively deployed in the production environment.”

Images outside the window cannot remain actively deployed in production, and the deployment pipeline should incorporate scanning when possible.

2. Remediation Clocks Run From Discovery

CVE remediation timelines require remediating critical and high Common Vulnerabilities and Exposures (CVE) findings within 30 days, moderate within 90, and low within 180. Unique vulnerability tracking assigns each vulnerability its own Plan of Action and Milestones (POA\&M) item, and raw scan output ships in the monthly ConMon submission when required by agency agreements.

Providers on the Consolidated Rules 2026, released June 24, 2026 and mandatory January 1, 2027, instead set remediation deadlines by each vulnerability’s PAIN rating and exploitability, including whether it appears in the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities Catalog. Detection cadence for machine-based resources, containers included, scales with certification class: representative samples at least every 7 days for Class B, every 3 days for Class C, and daily for Class D.

3. Unfixable Findings Need a Documented Deviation Request

FedRAMP deviation requests apply when a vendor dependency or operational requirement prevents remediation. They also apply to false positives, which require approval from the authorizing official.

4. The Registry Itself Is a Monitoring Target

“The container registry MUST be monitored per unique image to ensure that containers corresponding to an image that has not been scanned within the 30-day vulnerability scanning window are not actively deployed on production.”

Registry enforcement alternatives include alarms or other control mechanisms because a registry is often not a policy enforcement point.

These scanning and registry controls feed the runtime, inventory, and audit evidence required for continuous monitoring.

ConMon in Kubernetes Spans Runtime, Registry, and Asset Inventory

FedRAMP’s ConMon Playbook sets the monthly ConMon submissions, and Kubernetes changes how each one is produced.

• Runtime detection inside pods (SI-4) requires kernel-level visibility. Kubernetes API audit records capture requests to the Kubernetes API but cannot satisfy SI-4 on their own. Falco runtime monitoring, a graduated Cloud Native Computing Foundation (CNCF) project, reads kernel system calls and enriches them with Kubernetes context.  
• Registry monitoring is enforced per unique image. The container registry must monitor each unique image so images outside the 30-day scanning window are not actively deployed in production.  
• Inventory refresh must be automated (CM-8). The playbook requires unique tags for all ephemeral assets. Each image class gets a unique asset identifier in the Integrated Inventory Workbook, and an automated mechanism tracks running instances; the assessor validates this. Because containers are replaced rather than patched, remediation can run through infrastructure-as-code manifests.  
• Audit logs go to a separate, tamper-evident store (AU-2, AU-9). Kubernetes audit logging requires an audit policy and a configured backend. The webhook backend ships events to a remote API; configuring that destination on a physically different system meets AU-9(2)’s requirement, and AU-9(3) adds cryptographic integrity protection.

Building and maintaining these evidence streams places substantial infrastructure work on the product team. A pre-authorized orchestration boundary changes that calculus, because vendors can inherit the underlying control implementations rather than construct and defend them independently.

That inheritance model is what turns Kubernetes from a compliance burden into a certification accelerator.

A Pre-Authorized Boundary Turns Kubernetes FedRAMP Certification Into a 90-Day Path

Boundary placement determines inheritance. Runtime and orchestration security includes control-plane hardening, runtime sensors, and audit-log storage, and vendors that inherit those layers from a pre-authorized platform can reach FedRAMP certification in roughly 90 days at about 90% less cost than the traditional route.

Knox Systems operates a FedRAMP-as-a-Service platform whose pre-authorized boundary enables SaaS vendors deployed inside it to inherit up to 80% of required NIST SP 800-53 Rev5 controls, significantly shrinking the documentation scope. The platform covers FedRAMP Moderate, FedRAMP High, and Defense Information Systems Agency (DISA) Impact Level 4 (IL-4). Impact Level 5 (IL-5) authorization is in process, with an estimated completion date of December 2026.

Book a demo to see how Kubernetes workloads map onto that boundary.

FAQs about FedRAMP and Kubernetes

What Does Kubernetes Container Orchestration Do?

Kubernetes places containers onto nodes based on resource requirements, gives each set of pods a single Domain Name System (DNS) name with load balancing, restarts crashed containers, replaces failed pods, and rolls out configuration changes while watching application health. These functions let teams define the desired application state while Kubernetes continually reconciles the running environment against it.

Does Running on Kubernetes Make FedRAMP Certification Harder or Easier?

It depends on the operating model. Kubernetes can make certification easier when standardized controls replace per-service implementation, but harder when teams lack automated inventory, scanning, and evidence collection. Managed Kubernetes shifts control-plane hosting to the provider without transferring responsibility for cluster configuration or deployed workloads.

Which Container Runtimes Does Kubernetes Support for FedRAMP Workloads?

Kubernetes container runtimes must conform to the Container Runtime Interface (CRI), such as containerd or CRI-O. Dockershim was removed in v1.24, so Docker Engine now needs cri-dockerd. Runtime choice does not change the hardening, inventory, and scanning obligations applied to Open Container Initiative (OCI) images inside the boundary.

Is a FedRAMP Certification Specific to a Container Image or the Whole System?

An image is a configuration item within the certified system, not the certification object itself. The operational question is whether a replacement follows the approved image class and deployment controls, not whether it needs its own certification.

‍