Running Kubernetes in a FedRAMP Boundary: Requirements and How Knox Handles Them

Most Software as a Service (SaaS) companies pursuing Federal Risk and Authorization Management Program (FedRAMP) authorization today run Kubernetes somewhere in their stack.

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 applies control requirements to whatever architecture a system uses. NIST SP 800-190 maps NIST 800-53 controls to container security concerns. System Security Plan (SSP) guidance makes clear that these layers are assessable during authorization and must be documented in the SSP.

Teams often run Kubernetes one way in commercial environments and another under FedRAMP operational requirements, and that gap can delay authorization. This article maps each requirement to the Kubernetes layer it affects and identifies where the infrastructure-layer burden can be resolved before a vendor writes application documentation.

Key Takeaways

• Boundary scope. FedRAMP controls apply to Kubernetes components and layers within the defined authorization boundary. Base images, pod-to-pod communication, Continuous Integration and Continuous Deployment (CI/CD) runners, and container scanning all map to specific NIST SP 800-53 control families that must be satisfied within that boundary.  
• FIPS requirements. Federal Information Processing Standards (FIPS) validated base images and encryption in transit are requirements. FedRAMP requires validated cryptographic modules when cryptography is used to protect federal systems or information, and the use of unvalidated modules may be documented and managed through Plan of Action and Milestones (POA\&M) entries in some contexts.  
• Monitoring burden. Continuous monitoring obligations depend on the system boundary and the assets and components in scope. Each container image type can increase the workload for vulnerability scanning and remediation tracking under FedRAMP's 30/90/180-day remediation service-level agreements (SLAs).  
• Inherited controls. Pre-authorized boundaries absorb infrastructure-layer controls. Inheriting FIPS image provisioning, cluster-level encryption, scanning infrastructure, and access tooling reduces the vendor's authorization scope to the application layer.

What Is Kubernetes?

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications across clusters of compute nodes. It groups containers into logical units called pods, schedules them onto worker nodes, and exposes them through services, networking policies, and an API server that manages the cluster state.

In a FedRAMP context, Kubernetes is treated as a multi-layered system component. The control plane, worker nodes, container images, network policies, and deployment pipelines each fall within the authorization boundary, and each layer is assessed against the relevant NIST SP 800-53 control families.

FedRAMP Allows Kubernetes and Applies Controls at Every Layer of the Stack

FedRAMP authorization applies controls to any architecture a SaaS vendor chooses. A vendor can run Kubernetes, virtual machines, serverless functions, or any combination, and the compliance obligation is to satisfy the applicable controls at the layers where they apply. NIST SP 800-190 maps specific 800-53 controls to container security concerns, and SSP guidance requires those layers to be documented in the SSP.

For Kubernetes specifically, the in-scope controls include:

• Access control (AC) and audit (AU). Role-based access control (RBAC), namespace isolation, and API server audit policies enforce least privilege and produce the audit evidence required at the cluster layer.  
• Configuration management (CM). Base image hardening, admission policies, and IaC-defined cluster configuration support CM-2, CM-6, and CM-8 inventory and baseline requirements.  
• System and communications protection (SC). Network policies, mutual TLS (mTLS) between pods, and TLS at ingress satisfy SC-8 and SC-13 expectations for encryption in transit.  
• System and information integrity (SI). Vulnerability scanning pipelines for container images and running workloads support SI-2 flaw remediation and RA-5 scanning obligations.

The authorization effort is proportional to how many of those layers a vendor owns. Base images sit at the center of that ownership question because they determine which cryptographic modules, patching practices, and validation evidence are available to the workload.

FIPS-Validated Base Images Are a Hard Requirement

Teams coming from commercial Kubernetes are accustomed to pulling base images from public registries, scanning them in CI/CD, and shipping. FedRAMP's SC-13 control and the January 2025 cryptographic policy push that model toward a more explicit risk-based approach.

Cryptographic modules used by containers processing Controlled Unclassified Information (CUI) must be FIPS-validated or National Security Agency (NSA) approved, and container-based images may require independent FIPS module validation.

A container image is FIPS-validated only when the following conditions hold:

• The cryptographic modules (OpenSSL, BoringCrypto, or equivalent) within the image are traceable to an active Cryptographic Module Validation Program (CMVP) certificate  
• The running process uses validated code paths. Enabling fips=1 at the host kernel level does not force user-space applications or containers to use validated modules.  
• The operational environment under which the module was tested matches the deployed environment. Patching a base image, even for a Common Vulnerabilities and Exposures (CVE) entry, can break the validated operational environment.

"Continuously updated" means the vendor maintaining the FIPS-validated image must release patched versions that preserve the validated cryptographic boundary while addressing new CVEs. This creates a persistent tension. CVE remediation obligations, including 30-day remediation for Critical and High findings, require frequent image updates, but each update risks breaking FIPS validation status. Procuring and maintaining FIPS-validated images introduces additional vendor and operational costs.

Every Data Path Inside the Cluster Requires Encryption With FIPS-Validated Modules

FedRAMP's SC-8 and SC-13 controls require FIPS-validated encryption in transit for all communications, including traffic entering or leaving the boundary and internal cluster traffic. FedRAMP's cryptographic policy requires CSPs to define, identify, and document all areas where cryptographic functions occur.

Data paths requiring explicit FIPS-validated TLS configuration:

• External traffic: Load balancer to backend services. TLS termination at the load balancer, with unencrypted forwarding to backend pods, fails to meet FedRAMP requirements. Traffic handling behind load balancers should be designed to meet the system's security and authorization-boundary requirements.  
• Internal service-to-service: Pod-to-pod communication, both cross-node and same-node. Internal cluster traffic is still in scope for SC-8 protection.  
• Data layer: Database and cache connections, including Redis and ElastiCache. AWS ElastiCache does not support mTLS; it supports TLS for in-transit encryption.  
• Service mesh option: Istio with images configured to use FIPS-validated cryptographic modules for cluster-wide mTLS. Standard Istio images are not FIPS-validated. Both FIPS-built images and the ISTIO_META_JSON_LABELS='{"istio":"fips-140-2"}' setting are required. Istio's default PERMISSIVE mode accepts plaintext connections alongside mutual TLS traffic, which may not meet FedRAMP encryption-in-transit expectations.

Two implementation paths exist: per-service TLS configuration and service mesh. Per-service TLS works for small deployments but creates fragmented audit evidence and no centralized enforcement mechanism. A service mesh like Istio can centralize mTLS policy enforcement, automate certificate rotation, and produce logs and configuration outputs that may support SC-13 documentation. FedRAMP still requires cryptographic functions to be traced to FIPS-validated modules rather than relying on a merely FIPS-capable service mesh.

Encryption controls across internal traffic also pull the systems that build, approve, and deploy workloads into the compliance boundary.

CI/CD Pipelines and IaC Coverage Requirements Change How Kubernetes Deployments Work

In a Kubernetes-based FedRAMP environment, deployment systems are part of the control environment. The same boundary logic that pulls internal traffic, images, and runtime configuration into scope also pulls in the systems that execute infrastructure changes and application releases. CI/CD pipelines and Infrastructure as Code (IaC) practices, therefore, become questions of authorization.

Self-Hosted Runners Are Required Inside the Boundary

The deployment runner is a system component, and its placement determines whether it sits inside or outside the authorization boundary.

Cloud-hosted runners like GitHub Actions default runners, CircleCI cloud runners, and GitLab shared runners operate outside the boundary, so any runner that handles federal data must be brought inside, replaced, or removed from the federal data path. "Self-hosted inside the boundary" means the runner compute executes on infrastructure that is physically or logically within the authorized cloud environment, even though the upstream repository and workflow triggers can remain external.

Deployments executed through those runners are also subject to significant-change processes and agency approval, where required and should follow documented configuration management that supports CM-2, CM-3 and CM-5.

IaC Coverage Is a Pre-Authorization Requirement

IaC coverage is what makes the deployment system auditable, and the "no click-ops" rule requires that changes be executed by redeploying version-controlled, immutable resources rather than by direct console modification.

Acceptable tooling includes Terraform, Pulumi, CloudFormation, and Ansible, with Gatekeeper (Open Policy Agent) and Kyverno enforcing Kubernetes-specific policy and preventing configuration drift.

Pre-deployment IaC scanning validates templates against cloud resource configuration requirements before execution, catching misconfigurations before they reach the cluster. Gaps found during assessment become findings relative to the baseline and inventory expectations defined by CM-8, since infrastructure defined outside IaC is much harder to track in the system component inventory and to map to scan results.

Inventory discipline continues after go-live, as container scanning becomes part of monthly operations rather than a one-time gate.

Container Scanning Is a Continuous Monitoring Obligation With Defined Remediation SLAs

FedRAMP's container scanning requirements make scanning part of continuous monitoring, with vulnerability scanning performed at least monthly. Only containers from images scanned within a 30-day vulnerability scanning window may be actively deployed in production, and registry monitoring per unique image enforces that cadence. CVE remediation in containerized environments often involves building a replacement image, scanning it, and redeploying it rather than patching running containers in place.

FedRAMP-mandated remediation timelines begin on the date of discovery and increase with severity. Critical and High findings carry a 30-day remediation SLA; Moderate findings must be remediated within 90 days; and Low findings are documented in the POA\&M with an 180-day SLA.

Finding volume in Kubernetes environments is driven by specific architectural characteristics:

• Number of running container image types. The ConMon Playbook requires scan variance analysis within unique inventory groups, so creating more distinct inventory groups can increase analysis overhead.  
• Base image update cadence. CVEs in a base image propagate across all images built from it, and an upstream vulnerability can affect many tracked assets at once.  
• Third-party dependencies in application containers. Libraries bundled into application images carry their own CVE surfaces, and each is independently tracked.  
• Immutable-image patching model. In immutable container-based environments, remediation is typically handled through a build-scan-redeploy cycle instead of patching a running container in place.

Many of these obligations exist at the infrastructure layer, below the application layer, but FedRAMP responsibilities can vary depending on the system boundary, architecture, data flows, and inherited controls.

The question is not only how to document Kubernetes inside a FedRAMP boundary. It is whether the infrastructure layer needs to be built and evidenced by the SaaS vendor at all.

A Pre-Authorized Kubernetes Layer Eliminates the Infrastructure Control Burden

The requirements above, including FIPS-validated images, FIPS-encrypted data paths, self-hosted runners, IaC enforcement, and continuous container scanning, are infrastructure-layer obligations below the application. When a vendor resolves each of these independently, the cost and timeline reflect the full stack. When a vendor's Kubernetes workload runs inside a pre-authorized boundary, these controls are already in place and inherited.

Knox is a FedRAMP-as-a-Service platform that enables SaaS companies to achieve federal authorization in approximately 90 days at approximately 90% less cost than traditional methods. Its pre-authorized infrastructure boundary spans Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP).

For Kubernetes workloads, the pre-authorized layer absorbs:

• FIPS base image provisioning. Subscribers receive bundled access to FIPS 140-3 validated, Security Technical Implementation Guide (STIG) benchmarked, and Center for Internet Security (CIS) benchmarked container images as part of their existing subscription.  
• Scanning infrastructure and ConMon reporting. The offering includes scanning infrastructure, penetration testing, static code analysis, and IaC scanning, all of which exceed FedRAMP's monthly minimum. POA\&M automation and monthly reporting are handled at the boundary level.  
• Self-hosted runner requirements and IaC validation. The Knox FedRAMP boundary requires CI/CD pipelines for deployments and as close to 100% IaC coverage as possible, with supported tooling including GitHub Actions, Jenkins, and ArgoCD.  
• Access tooling and identity management. Infrastructure-layer FIPS controls and environment configuration are inherited by vendors deploying within the Knox FedRAMP boundary.

The vendor retains ownership of application code, deployment pipeline configuration, application-layer secrets management, and application-specific RBAC policies. Inherited controls are documented as such in the SSP, reducing the scope of what the SaaS provider must implement and evidence independently. Those inherited controls shorten the path toward FedRAMP authorization.

Kubernetes Authorization Is an Infrastructure Problem First

Control families often relevant to Kubernetes-based FedRAMP authorizations, including SC-13 for cryptographic protection, SC-8 for protecting transmitted information, CM-2 and CM-3 for configuration management, and RA-5 for vulnerability scanning, map to infrastructure and container platform requirements documented in NIST and FedRAMP guidance. Solving them independently, per vendor, per authorization, is the structural reason authorizations become longer and more expensive when teams must own the full stack themselves.

Knox Systems runs the infrastructure layer at the boundary once, so engineering teams can focus their authorization efforts on the application layer, where their product actually lives. The platform is built for exactly this split: infrastructure controls inherited on day one, and application-layer authorization scoped to what the vendor actually built. Subscribers reach authorization in approximately 90 days at approximately 90% less cost than traditional paths.

Ready to shorten your Kubernetes authorization timeline? Book a meeting with the Knox team.

FAQs About Kubernetes in a FedRAMP Boundary

Can Managed Kubernetes Services Such as EKS, AKS, or GKE Be Used Within a FedRAMP Boundary?

Managed Kubernetes services can be used when the underlying cloud service offering is FedRAMP-authorized at the required impact level. The control plane is typically inherited from the provider, while node configuration, workloads, and add-ons remain the customer's responsibility to document in the SSP.

How Is Kubernetes etcd Encryption Handled Under FedRAMP?

Etcd stores cluster state and secrets, so it falls under SC-28 protections for information at rest. Encryption at rest must use FIPS-validated modules, and key material must be managed through an approved key management service rather than static configuration files.

What Happens to Kubernetes Workloads When a FIPS-Validated Module Moves to the Historical List?

A module on the Historical List is no longer considered an acceptable choice for new procurements, though existing deployments may continue under defined conditions. Vendors should plan migration to a current validated module before the transition date and document the plan in their ConMon artifacts.

Are Kubernetes Admission Controllers Required for FedRAMP Authorization?

Admission controllers are not named in FedRAMP guidance, but they are a practical way to enforce CM-7 least-functionality and CM-6 configuration settings. Policy engines such as Gatekeeper or Kyverno are commonly used to block non-compliant workloads at deployment time.

How Does Kubernetes Secrets Management Map to FedRAMP Control Requirements?

Native Kubernetes secrets are base64-encoded rather than encrypted by default, so most FedRAMP environments integrate with an external secrets manager backed by FIPS-validated cryptography. This supports IA-5 authenticator management and SC-12 cryptographic key establishment requirements.