Chapter 2: Machine-Readable Compliance
OSCAL SSP Template for Kubernetes Platforms
The End of the Word Document Era
For decades, federal security documentation has lived in Word documents and Excel spreadsheets. System Security Plans stretch to hundreds of pages. Control matrices sprawl across dozens of tabs. Version control means filenames like "SSP_Final_v3_REVISED_actualfinal.docx." Assessors spend weeks cross-referencing documents that were outdated the moment they were exported.
OSCAL—the Open Security Controls Assessment Language—eliminates this dysfunction. Developed by NIST, OSCAL provides a standardized, machine-readable format for security documentation. Instead of prose that humans must interpret, OSCAL produces structured data that tools can validate, compare, and process automatically.
For Kubernetes platforms pursuing continuous ATO, OSCAL is not optional. It is the technical foundation that makes automated compliance possible. When your System Security Plan exists as structured data, you can programmatically verify that every control has an implementation statement, that every implementation references valid evidence, and that changes to your platform trigger corresponding updates to your documentation.
The transition requires investment, but organizations that adopt OSCAL report transformative results: assessment preparation time drops from months to days, documentation stays synchronized with actual configurations, and authorizing officials gain confidence in the accuracy of what they review.
Understanding OSCAL Structure
OSCAL defines several interconnected models, but three matter most for platform authorization:
Catalog: The definitive list of controls against which you assess. For federal systems, this is typically NIST 800-53 Revision 5, though OSCAL supports FedRAMP baselines, CNSSI 1253, and custom control sets.
Profile: A selection and tailoring of controls from a catalog. Your profile defines which controls apply to your system, any parameter values you've set, and modifications like added guidance or scoped applicability.
System Security Plan (SSP): The comprehensive documentation of your system, including its description, authorization boundary, components, and—critically—how each control is implemented.
These models reference each other through explicit links. Your SSP points to the profile it implements. The profile points to the catalog it derives from. This chain of references ensures traceability and enables tooling to validate completeness automatically.
Anatomy of an OSCAL SSP
An OSCAL SSP contains several major sections that map directly to traditional SSP content, restructured for machine processing.
Metadata: Basic information including the SSP title, version, last modification date, and responsible parties. This section also defines roles—Information System Security Officer, Authorizing Official, System Owner—and associates them with specific individuals.
System Characteristics: Describes the system itself, including its purpose, authorization boundary, network architecture, and data types processed. For Kubernetes platforms, this section defines whether you're documenting the platform itself, the applications running on it, or both.
System Implementation: Enumerates the components that constitute your system. Each component—whether a Kubernetes cluster, an ingress controller, a service mesh, or a logging pipeline—is defined as a discrete entity with its own properties. Components can be marked as providing control implementations that other components inherit.
Control Implementation: The heart of the SSP. For each applicable control, you document one or more implementation statements describing how your system satisfies the requirement. Statements link to specific components, reference evidence artifacts, and indicate whether the implementation is complete, planned, or not applicable.
Practical OSCAL Examples
The following excerpts demonstrate how Kubernetes-specific implementations appear in OSCAL format.
Component Definition: Kubernetes Cluster
components:
- uuid: cluster-primary-001
type: service
title: Production Kubernetes Cluster
description: >
Amazon EKS cluster running Kubernetes 1.28 with managed
node groups. Serves as the primary container orchestration
platform for mission applications.
props:
- name: kubernetes-version
value: "1.28"
- name: cloud-provider
value: aws-govcloud
- name: cluster-endpoint-access
value: private
status:
state: operational
This component definition captures not just what the cluster is, but queryable properties that assessors and automated tools can reference. When a control implementation states "the cluster restricts API access to private endpoints," tooling can verify that cluster-endpoint-access: private supports that claim.
Control Implementation: AC-6(1) — Least Privilege, Authorize Access to Security Functions
implemented-requirements:
- uuid: impl-ac-6-1-001
control-id: ac-6.1
statements:
- statement-id: ac-6.1_stmt
uuid: stmt-ac-6-1-001
description: >
Access to security-relevant Kubernetes functions is restricted
through RBAC ClusterRoles. The 'cluster-security-admin' role
grants access to PodSecurityPolicies, NetworkPolicies, and
audit configurations. This role is bound only to members of
the Platform Security team via Azure AD group synchronization.
by-components:
- component-uuid: cluster-primary-001
uuid: by-comp-001
description: >
RBAC configuration stored in cluster-rbac/ directory of
platform GitOps repository. Group synchronization configured
via Azure AD Connector.
implementation-status:
state: implemented
Notice how the implementation statement references the specific component, describes both what is implemented and how, and declares the implementation status. An assessor reviewing this entry knows exactly which system component to examine and where to find the configuration.
Lessons from OSCAL Adoption
Organizations that have migrated from traditional documentation to OSCAL share hard-won insights.
Start with a single control family. Converting an entire SSP to OSCAL simultaneously overwhelms teams and delays value realization. Begin with one high-impact family—Access Control or Audit are good candidates—and build proficiency before expanding. The patterns you establish in the first family become templates for the rest.
Invest in OSCAL-aware tooling. Raw OSCAL files are verbose and difficult to author by hand. Tools like Trestle, Compliance-Trestle, and OSCAL-CLI provide scaffolding for creating, validating, and transforming OSCAL content. Commercial governance platforms increasingly support OSCAL import and export. The tooling ecosystem matures monthly; evaluate options before committing to manual authoring.
Link components to infrastructure-as-code. The greatest OSCAL value comes from connecting SSP components to their actual definitions. If your Kubernetes cluster is defined in Terraform, your OSCAL component definition should reference that Terraform module. When the module changes, your documentation pipeline can flag the SSP for review. This linkage transforms documentation from a point-in-time artifact to a living representation of your system.
Validate continuously. OSCAL's machine-readable format enables automated validation that was impossible with Word documents. Build pipeline stages that verify every control has at least one implementation statement, every statement references a valid component, and every component marked "operational" has corresponding evidence. Run this validation on every commit to your documentation repository.
Practical Tips for Your First OSCAL SSP
Use YAML over JSON. OSCAL supports both formats, and they are semantically identical. YAML's readability makes reviews easier and diffs more meaningful in version control. Reserve JSON for tool interchange where parsing efficiency matters.
Establish UUID conventions. OSCAL relies heavily on UUIDs for cross-referencing. Adopt a naming pattern—perhaps component UUIDs start with comp-, implementations with impl-—that helps humans navigate the document while maintaining uniqueness.
Create inheritance hierarchies. Define your platform components once and mark them as providing inherited control implementations. Application teams authoring their own SSPs can then reference your platform SSP rather than re-documenting controls you already satisfy. This mirrors the FedRAMP leveraged authorization model in machine-readable form.
Version your OSCAL alongside your code. Store SSP files in the same Git repository as your platform definitions, or in a dedicated repository with clear branching and tagging conventions. Treat documentation changes with the same rigor as code changes: pull requests, reviews, and approvals before merge.
Your Next Step
Download the OSCAL SSP starter template included with this ebook. The template provides the structural scaffolding for a Kubernetes platform SSP with placeholder components, example control implementations, and embedded comments explaining each section. Fork it into your own repository, replace the placeholders with your actual system details, and begin documenting your first control family. Within a week, you will have a working OSCAL SSP that can grow with your platform.
Free Resource: Skip the Learning Curve
Kubernetes Platform OSCAL SSP Starter Kit
Don't spend weeks figuring out OSCAL syntax. Get a production-ready template built specifically for Kubernetes platforms.
What's included:
- Complete YAML SSP structure with inline documentation
- 15 pre-written control implementations for common Kubernetes controls
- Component definitions for EKS, AKS, and GKE platforms
- Validation scripts to check your SSP for errors before submission
- Step-by-step customization guide with video walkthrough
[Download the OSCAL Starter Kit]
Enter your email to get instant access. You'll also receive practical tips for accelerating your ATO delivered weekly.