Why agencies deploy Kubernetes on their own networks
A self-managed Kubernetes platform fits an agency that must run applications on infrastructure it controls, including networks with no internet access, when the build plans image supply, identity, hardening, etcd backups and version support from the start. These decisions are hard to add after workloads arrive, and the control frameworks that apply to agencies, such as the control catalog in NIST SP 800-53 Rev. 5, expect evidence for each of them. The current release of that catalog is 5.2.0. The SP 800-53B baselines select 149 controls and enhancements for low impact systems, 287 for moderate and 370 for high. The authorizing official decides which baseline applies, so confirm it before the design is fixed.
The biggest change from a commercial or internet-connected cluster is where the platform gets what it needs. A connected cluster pulls images, charts and patches on demand, and an isolated one cannot. Kubeadm can list and pull the control plane images in advance with kubeadm config images list and kubeadm config images pull, and the --image-repository flag points kubeadm init at a private registry. Every other image, operator and add-on has to be mirrored, scanned and verified through a process the agency owns. Identity changes too. Kubernetes does not store human users as API objects, so the team must choose how users authenticate, whether with X.509 client certificates, OpenID Connect tokens from the agency's identity provider, or an authenticating proxy, and then map groups to RBAC roles.
Hardening decisions follow. Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest must be configured on day one, and list and watch access on Secrets should be limited with least-privilege RBAC. Pod Security Standards define three levels, Privileged, Baseline and Restricted, which the built-in Pod Security Admission controller enforces per namespace. A common starting point for application namespaces is Restricted, with each exception documented and approved. The CIS Kubernetes Benchmark is a consensus configuration guide that covers upstream Kubernetes and several managed services, so it can serve as the reference for the agency's own checks. Ask the distribution vendor which benchmark profile its default configuration follows and where it differs.
Plan the etcd and upgrade routine before go-live, because both are hard to repair under pressure. The kubeadm high availability guide describes stacked control plane nodes or an external etcd cluster, with at least three control plane nodes behind a TCP load balancer on port 6443. etcd should run with an odd number of members, and the Kubernetes documentation recommends five members in production. Take backups with etcdctl snapshot save, restore with etcdutl, and rehearse a restore on a separate cluster. The project maintains the three most recent minor releases. As of September 2026, those were 1.37, end of life October 28, 2027, 1.36, June 28, 2027, and 1.35, February 28, 2027. Confirm these dates on the Kubernetes releases page before committing to a version, and upgrade one minor version at a time, starting with the API server.
Evidence is the last piece. DeployOpen plans and builds the cluster, hardens it, sets up backups and documents the configuration, and it prepares controls and evidence for assessment. It does not issue audit reports, attestations or certifications. Those decisions belong to the agency's authorizing official and to independent assessors or certification bodies. Before the scope is signed, ask for a written mapping of each control in the agreed baseline to a cluster setting, log source or document, and confirm which systems fall inside the authorization boundary. Whether a platform counts as a cloud service also changes which federal program applies, so settle that question with the agency's compliance office first.
Which public sector requirements shape the Kubernetes build
This table lists the public sector requirements that most affect a self-managed Kubernetes cluster, the source each one comes from and the design consequence for the build. Read each row as a design input to settle before hardening starts. The main takeaway is that baseline selection, cryptographic modules, scan scheduling and CUI isolation are decided at design time, and changing them later costs more than setting them early.
| Requirement | Source | What it means for the build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | NIST SP 800-53B baselines, Release 5.2.0 of 27 August 2025 | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements. Confirm the baseline with the authorizing official before design freezes. |
| FISMA and Inspector General assessment | NIST Risk Management Framework FAQs | Inspectors General assess agency systems independently. Keep audit logs, RBAC exports and configuration baselines retained and exportable for reviewers. |
| CJIS encryption for CJI | FBI CJIS Security Policy v6.1, controls SC-13 and SC-28 | Use FIPS 140-3 certified modules or AES with 256-bit keys. Cover etcd encryption, etcd snapshots and ingress TLS, and confirm the distribution's crypto modules. |
| CJIS vulnerability scanning | FBI CJIS Security Policy v6.1, control RA-5 | Scan at least monthly. Schedule image and node scans as recurring jobs and keep the results as evidence. |
| CUI on non-federal systems | 32 CFR 2002.14(h)(2) | Agencies apply NIST SP 800-171 to CUI on contractor systems unless another authority sets safeguards. Isolate CUI namespaces, nodes and backups from other workloads. |
| NIS2 coverage of public administration | Directive (EU) 2022/2555, Articles 2 and 3, Annex I | Central government entities are covered regardless of size. Confirm whether the cluster serves an in-scope entity and whether local bodies are included. |
| FedRAMP scope for cloud-hosted services | OMB M-24-15 and FedRAMP scope rules | Cloud services that handle federal information for an agency fall in scope. Confirm with the agency whether a single-agency cluster is in scope. |
Which Kubernetes settings matter most in government environments
Government clusters depend on a small set of settings that shape identity, isolation, evidence and recovery. The cards below describe each decision, what it depends on and what to check before the build starts. A private container registry and internal package mirror belong to the same configuration so the cluster can be built and patched without internet access.
Conformant distribution choice
Choose a distribution listed in the CNCF Certified Kubernetes conformance program before comparing features. Conformance checks that a distribution supports the required Kubernetes APIs, and the CNCF page states there are over 90 certified offerings, so the shortlist narrows quickly. Ask the vendor or community project which exact Kubernetes version it certifies, how it ships security patches for that version, and whether its support terms cover air-gapped installation. Conformance does not replace your own hardening or evidence work.
Control plane and etcd recovery
Run at least three control plane nodes following the kubeadm high availability guide, with a TCP load balancer in front of kube-apiserver on port 6443. Choose stacked etcd, where etcd shares the control plane nodes, or an external etcd cluster, which adds hosts to operate but separates failure domains. Kubernetes documentation calls for an odd number of etcd members and recommends five in production. Take etcd snapshots with etcdctl snapshot save on a schedule, store them off the cluster, and rehearse restores with etcdutl, since a backup that has never been restored is unproven.
Directory-backed cluster authentication
Kubernetes does not store human users as API objects, so identity comes from outside the cluster. The main options are OpenID Connect or JWT bearer tokens issued by your identity provider, X.509 client certificates, webhook token authentication and an authenticating proxy. For agency directories, the design question is how group claims map to RBAC bindings and what happens when someone leaves the agency. Confirm which options your distribution exposes, how certificate revocation is handled and where break-glass accounts live outside the directory.
Secrets encryption and RBAC
Secrets are stored unencrypted in etcd by default, so configure encryption at rest for the Secrets resource before workloads store credentials. Pair it with least-privilege RBAC, paying particular attention to list and watch permissions, which can expose Secret values in bulk. Where the agency requires a central vault, the Secrets Store CSI Driver can pull values from an external store. Confirm who holds the encryption key material and how key rotation is rehearsed, because rotation procedures often go untested until an incident.
Pod Security Standards and CIS hardening
Pod Security Standards define the Privileged, Baseline and Restricted profiles, and the built-in Pod Security Admission controller enforces one of them per namespace. Set Restricted on workload namespaces where images allow it, and document exceptions for system namespaces. Use the CIS Kubernetes Benchmark as the audit baseline for control plane and node configuration, and record each recommendation you accept as a deviation. Confirm which benchmark version maps to your distribution, since managed and self-managed guidance differ in what they can check.
Audit logging and retention
Enable API server audit logging and decide which request stages, resources and namespaces are recorded before go-live. Audit policy design must be confirmed against your chosen distribution, because how the policy is configured and where logs are written varies by packaging. Set retention and access controls to match the agency's records and retention rules, and confirm who can read logs that contain sensitive request metadata. Forward logs to storage the cluster operators cannot silently edit, and test that alerts fire on the events the agency cares about.
How the air-gapped install gets images into the cluster
The air-gapped install depends on one rule: every image the control plane needs must be in the private registry before kubeadm init runs, because the cluster cannot fetch anything from the internet at that point. On a connected staging host, run kubeadm config images list for the exact Kubernetes version you plan to deploy, then run kubeadm config images pull to download those images. The list is the bill of materials for this step, so keep its output with the change record. The staging host should be the only machine in the process that talks to public registries, and the pulled images should be exported to an archive your transfer process can carry across the boundary.
Moving the archive across the boundary is where your own controls apply. Before anything is imported, verify software integrity and provenance for every image and every package. Compare digests against values the distribution publishes, check signatures against signing keys you have validated through your own trust process, and retain any build provenance records the vendor provides. Supply chain risk controls in NIST SP 800-53 and the software integrity expectations in NERC CIP-013-2 both point to this kind of evidence. Reject any artifact that fails a check, log the rejection with the reason, and do not import a partial set to save time.
After verification, load the images into the private registry under the repository path you will pass to kubeadm. Then run kubeadm config images pull on the target side with the registry set as the image repository, so you see failures before the control plane starts. Run kubeadm init with the image repository flag pointing at the same registry and the same Kubernetes version you verified. For example, an illustrative registry path such as registry.agency.internal/kubernetes would be used in every command. Confirm that each control plane image resolves from that registry before the first node joins, because a missing tag will otherwise surface as a stalled bootstrap.
Some pieces sit outside what kubeadm covers, so confirm them with the distribution vendor before you commit to a schedule. Ask for the offline installer bundle and its checksums, the list of add-on Helm charts and every image each chart references, and whether charts pin images by digest. Ask how update bundles are versioned against Kubernetes minor releases and how they are signed. Request the full image manifest for each bundle, including CNI, ingress and monitoring components. Then validate the whole chain in a test environment that matches your boundary, from staging host to registry to a cluster that boots with no outbound access, and record what you tested.
Compliance considerations for agency Kubernetes platforms
Agency Kubernetes platforms fall under several overlapping frameworks, and each one decides which controls the cluster must meet and which it inherits from the hosting environment. The cards below cover the federal control catalog, cloud authorization scope, criminal justice data rules, controlled unclassified information on non-federal systems and EU requirements. Each card lists the evidence the cluster can produce, while independent assessors and authorizing officials make the final determinations.
NIST SP 800-53 control selection
NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B groups its controls into low, moderate and high baselines. Agencies select a baseline for each system, then record in the system security plan which controls the cluster implements itself and which it inherits from the cloud provider or data center. Kubernetes evidence often includes RBAC bindings, Pod Security Admission settings, audit policy, etcd encryption configuration and exported hardening scan results. Confirm the baseline and the inheritance split with your authorizing official before drafting control statements.
FedRAMP scope for cluster hosting
FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A cluster that serves only one agency's operations and runs on infrastructure the agency operates is generally outside FedRAMP scope. Cloud shared services that host agency data for multiple customers are in scope, so a managed Kubernetes service or vendor-run platform needs its authorization status checked. Ask the provider for its FedRAMP package and confirm which responsibilities it covers. The authorizing official makes the scope determination.
CJIS encryption and scanning expectations
The FBI CJIS Security Policy sets minimum requirements for criminal justice information. Version 6.1 took effect on 26 June 2026 and expects either FIPS 140-3 certified modules or AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations. Vulnerability scanning must run at least monthly. For the cluster, confirm ingress TLS, etcd encryption at rest, node disk encryption and the scanner schedule, and keep the configuration and scan reports. The agency's CJIS representatives and auditors decide compliance.
CUI handling on non-federal systems
Under 32 CFR 2002.14(h)(2), federal agencies use NIST SP 800-171 to set protection requirements for controlled unclassified information on non-federal systems, unless the CUI category's authority prescribes other safeguards. When a contractor or grantee runs a Kubernetes platform that holds CUI, the cluster falls under those requirements. Evidence includes access control records, audit logs with defined retention, encrypted storage and transit, and documented configuration baselines. Defense contractors also face conditions in 32 CFR 170.17 for storing CUI in cloud services. Confirm the requirements in the contract with the agency.
NIS2 for EU public administration
NIS2 (Directive (EU) 2022/2555) covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration. It does not apply to entities working in national security, public security, defense or law enforcement, so those platforms need a separate scope determination. For covered entities, the cluster can supply risk management records, incident detection from audit logs, access reviews and patch history. Confirm with your national competent authority how the directive is transposed in your Member State.
How a public sector Kubernetes rollout is sequenced
The sequence moves from agreeing the system boundary with the system security plan owner to a hardened, operated cluster with a tested recovery path and an upgrade runbook. Each phase closes with a check the agency can inspect, so approvals and evidence are in place before workloads arrive. Phase lengths depend on the agency's approval cycle and are set in the written scope.
Define scope and boundary with the SSP owner
Work with the system security plan owner, the agency security team and any assessors to set the system boundary, the data the cluster will hold, the connected systems and the control baseline it will be assessed against. Record the boundary diagram, the in-scope and out-of-scope components and the named control owners. The step is done when the owner signs the boundary and scope document. The approval cycle sets how long this takes, so the schedule is fixed in the written scope once approvals are known.
Choose architecture and distribution
Select the distribution, the Kubernetes minor version, the control plane topology (stacked etcd or an external etcd cluster), node sizing, storage and ingress. Check the chosen version against the supported release list and its end-of-life dates, and confirm with the distribution vendor that it is conformant and supported for air-gapped operation. Conformance shows API compatibility, not security hardening, so ask for both. The output is an architecture decision record that includes the version policy and the planned upgrade path.
Stage the offline image and package bundle
Build an inventory of control plane images, add-on images, operating system packages and Helm charts. On a connected staging network, pull the control plane images with the kubeadm image list and pull commands, then push everything to the private registry that kubeadm init will reference through its image repository flag. Verify checksums and signatures against vendor-supplied artifacts before anything crosses the boundary. The step is done when the registry matches the manifest and a test node installs with no outbound access.
Build the HA control plane with identity integration
Build at least three control plane nodes behind a TCP load balancer that fronts the API server on port 6443. Use an odd number of etcd members, and confirm the member count and placement against the topology chosen earlier. Configure API server authentication against the agency's OpenID Connect identity provider, and keep a separately controlled certificate-based path for break-glass access. The step is done when a test control plane node is stopped and the API remains reachable through the load balancer.
Harden against the CIS Benchmark with documented exceptions
Run a CIS Kubernetes Benchmark assessment against the cluster, using the benchmark version that matches the Kubernetes release, and remediate the findings. Enable encryption at rest for Secrets, because they are stored unencrypted in etcd by default, and restrict list and watch access with least-privilege RBAC. Record every accepted deviation in an exception register with an owner, the reason, a compensating control and a review date. The step is done when the scan report and the exception register have been reviewed by the control owners.
Enable audit logging and test the etcd restore
Configure an API server audit policy and forward audit logs off the cluster to the agency's log platform so that a compromised node cannot alter them. Take etcd snapshots with etcdctl snapshot save on a schedule, then restore one into a separate test cluster using etcdutl. Record how long the restore took and which steps were manual. The step is done when a restore has completed successfully and the recovery procedure is written down and checked by the operations team.
Onboard workloads under Pod Security enforcement
Create namespaces for each workload owner and set Pod Security Admission labels per namespace, using the Baseline or Restricted standard wherever the workload allows it. Add network policies, scoped RBAC bindings and an admission rule that only permits images from the private registry. Confirm enforcement by attempting to deploy a non-compliant pod in a test namespace and checking that it is rejected. The step is done when the rejection test and the first onboarded workload both pass review.
Hand over with an upgrade and patch runbook
Deliver a runbook for minor version upgrades, performed one minor version at a time in the order set by the version skew policy: the API server first, then the controller manager and scheduler, then the kubelets within the permitted skew. The runbook also covers an etcd snapshot before each change, re-staging images and packages through the boundary, and the patch cadence the agency has approved. The step is done when the operations team completes a rehearsal of an upgrade in staging and signs off the handover.
Choosing a supported distribution and version window
The CNCF Certified Kubernetes conformance program checks that vendor and community distributions support the Kubernetes APIs that workloads and tooling expect. The CNCF page states there are over 90 Certified Kubernetes offerings, so conformance narrows the field without settling the choice. Treat it as a baseline for API compatibility and nothing more.
- Certified version: Ask for the conformance result for the exact release you plan to deploy, not for the product line in general.
- Listing: Confirm the offering appears on the CNCF listing and that the product name and version match the vendor's documentation.
- Scope: Conformance covers API behavior. It does not cover hardening, cryptographic module validation, offline packaging or response times, so assess those separately.
- Modifications: Ask which components the vendor patches or replaces beyond upstream code and how each change is versioned against the certified build.
Before you shortlist a distribution, confirm that its conformance result covers the version you will install and the same build your private registry will mirror.
Conformance says nothing about who ships a fix when a vulnerability lands in a cluster that cannot reach the internet. Upstream Kubernetes maintains the three most recent minor releases. As of September 2026, the supplied dates were 1.37 with end of life on October 28, 2027, 1.36 on June 28, 2027 and 1.35 on February 28, 2027. Upstream patch support for 1.19 and newer is about one year, roughly 14 months including the pre-release period, and a vendor may commit to a longer or shorter window.
- Vendor end dates: Ask for the end-of-support date for each minor release the vendor ships, in writing, and compare it with the upstream dates above.
- Patch delivery: Confirm how backported fixes reach you, how they are signed and whether they arrive as offline bundles for your registry.
- Covered components: Confirm which add-ons, such as the CNI plugin, ingress controller and etcd packaging, fall under the same support agreement.
- Response terms: Ask for severity definitions and response commitments as written terms, and do not rely on verbal assurances.
Agencies must confirm the distribution vendor's own support terms, in writing, and check the end-of-support date for the target version before procurement approves the choice.
Upstream Kubernetes releases about three times a year on a cycle of about 14 weeks, so a cluster that is not upgraded on a schedule falls out of support quickly. The version skew policy sets the order of upgrades. The kube-apiserver must be upgraded one minor version at a time and before kube-controller-manager, kube-scheduler and kubelets. Kubelets may run up to three minor versions older than the kube-apiserver, which gives node rollouts room without removing the deadline.
- Upgrade order: Move the control plane one minor version at a time, then the controller manager and scheduler, then the node kubelets.
- Node lag: Use the three-minor kubelet allowance to schedule node rollouts around change freezes, and track how far behind each node pool runs.
- Window size: Set your target minor so its end-of-life date falls after your next planned upgrade cycle, with margin for testing.
- Testing lead time: Load the next minor into a staging cluster from your private registry before it becomes your target.
Confirm that the vendor will support each target minor through your planned window, and recheck the upstream release page before you approve the upgrade schedule.
What drives the cost and effort of a government Kubernetes build
Most of the one-time cost in a government Kubernetes build comes from work that happens before any cluster exists. Discovery and boundary work decides which systems, accounts, networks, registries and data flows fall inside the authorization boundary, and that decision sets the size of nearly every later task. Offline supply chain setup follows. kubeadm can pull control plane images in advance and point kubeadm init at a private registry through the --image-repository flag, but someone must mirror, verify, record and track every image, chart and operating system package that crosses into the enclosed environment. Hardening against the CIS Kubernetes Benchmark, Pod Security Admission settings per namespace, encryption at rest for Secrets and the collection of configuration evidence each add separate work. Ask the quote to show these as distinct line items so you can see which parts your own team could absorb.
The second block of one-time work covers identity, logging, backup testing and handover. Identity integration costs more when many systems must agree. Configuring API server authentication through OpenID Connect or another directory, mapping directory groups to RBAC roles and confirming that access revokes cleanly each require testing and sign-off. Audit logging integration requires deciding where API server audit events go, how long they are kept and who can read them. Backup testing is a one-time rehearsal that proves etcd snapshots made with etcdctl snapshot save can be restored with etcdutl in a clean environment. Handover covers runbooks, credential transfer, access reviews and training for the agency team. Retained support is optional and should appear as a separate line in the quote so it is not confused with the build price.
Recurring costs begin once the build is accepted and often exceed the build cost over the life of the platform. Kubernetes ships about three minor releases per year, and the project maintains only the three most recent minor versions, with roughly one year of patch support for each. Every minor upgrade must follow the version skew policy: kube-apiserver first, one minor version at a time, then kube-controller-manager, kube-scheduler and kubelets, which may trail the API server by up to three minor versions. Each upgrade also requires regression testing, backup verification and change approval. Vulnerability scanning of images and nodes recurs too, and some frameworks set a minimum frequency. The FBI CJIS Security Policy, for example, requires vulnerability scanning at least monthly for systems that process criminal justice information. Staff time to triage findings, apply patches and keep evidence current is the largest recurring item in most agencies.
Several drivers raise effort in both phases. The number of clusters multiplies almost every step, because each cluster needs its own etcd backups, certificates, policies, monitoring and upgrade run. A production control plane built with kubeadm uses at least three control plane nodes behind a TCP load balancer in front of port 6443, and etcd should run with an odd number of members, with five recommended for production. Air-gap maturity matters: an agency that already runs an internal registry, package mirror and approved transfer process will spend less on supply chain setup than one starting from nothing. Existing directory integration, assessment timelines and the number of control exceptions also add rework. Before accepting a quote, request a written scope that lists clusters by environment, the offline transfer procedure, the controls in scope, how exceptions are documented and approved, the assessment support included, and which recurring items are optional.
Questions agencies ask before hiring outside help
How much does a government Kubernetes build cost?
No single price applies, and DeployOpen does not publish a price list. A quote follows from the written scope, so the cost reflects the specific work you ask for. The main components are planning and architecture, the build itself (air-gapped image preparation, control plane and etcd setup, identity integration, hardening against the CIS Kubernetes Benchmark, audit logging), testing, and documentation with handover. Costs rise with the number of clusters, the number of environments (development, test, production and any isolated enclave), the number of identity sources and integrations, and the amount of evidence your assessor needs. Recurring costs include the infrastructure you run, staff time for patching and upgrades, and any support retainer. Ask each bidder to separate one-time work from recurring work and to name who performs each item.
How long does a government Kubernetes build take?
Duration depends on scope and on how quickly your side supplies inputs, so no fixed timeline applies to every agency. The largest drivers are approvals (security authorization, change boards and procurement), access to network and directory systems, whether the environment is air-gapped (which adds a private registry and an offline image pipeline), the number of clusters, and the number of integrations to identity, logging and storage. Kubernetes ships a new minor release about three times a year, so the version chosen at the start may need review if approvals run long. Confirm the target version against the Kubernetes releases page when you sign. Ask for a written plan with dated milestones and a list of dependencies on your side, so delays are visible early.
What must the agency provide before a Kubernetes build starts?
The build depends on inputs that only your organization holds. Expect to provide current network diagrams showing VLANs, firewalls, DNS and the path to any shared services, plus the data classification of the workloads the cluster will run. Directory access is needed for identity integration, so name the directory owner and the accounts or service principals that will be created. Approvals include the authorizing official or system owner, the change advisory process, and sign-off on the hardening baseline. You also need staff: a named technical owner, engineers who can attend working sessions, and someone who can accept hardware or virtual machine capacity. Ask the provider to send a written input list before the kickoff so you can schedule owners and access in advance.
Can our own team build a Kubernetes cluster without a partner?
Yes, many agencies build clusters with their own staff. The Kubernetes documentation covers the kubeadm high availability topologies, etcd snapshot backups and restores, and the authentication options, so the knowledge is public. The question is whether your team has time and skills for the specific tasks: an air-gapped installation, restore tests for etcd, certificate and Secrets handling, Pod Security Standards, audit logging, and upgrades several times a year. Check three things before deciding. First, whether at least two engineers can operate the cluster without the person who built it. Second, whether you can run an upgrade and a restore test in a non-production environment. Third, whether your change process allows the work on your schedule. A partner can take the whole build, only the hardening review, or the handover documentation.
Does DeployOpen issue certifications for our Kubernetes cluster?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. DeployOpen prepares the systems, controls and evidence an assessor will examine, such as configuration baselines, RBAC design, audit log settings, encryption at rest for Secrets, and backup and restore test records. Whether a cluster meets a framework depends on your authorization boundary, the decisions of your system owner and the findings of your assessor. For federal work, FedRAMP scope under OMB memo M-24-15 covers cloud products and services that handle federal information on behalf of an agency, and a system used only for one agency's operations on that agency's own infrastructure is generally out of scope. Confirm applicability with your authorizing official before you plan the evidence.
How are air-gapped Kubernetes image updates handled?
Updates move in a controlled sequence. Images are pulled on a connected staging network, checked, copied across the boundary into a private registry, and then referenced during installation or upgrade. kubeadm config images list and kubeadm config images pull fetch the control plane images in advance, and the --image-repository flag points kubeadm init at your private registry. Each update also includes add-on images and manifests for the network plugin, ingress and monitoring. Record the source, digest and approval for every item that crosses the boundary, scan images for known vulnerabilities before import, and verify signatures or checksums where the publisher provides them. Test each update in a non-production enclave first. Confirm your transfer media rules and review process with your security office before the first transfer.
How is a Kubernetes cluster supported after handover?
After handover, your team runs the cluster or buys ongoing support. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Either way, someone must own monitoring, etcd backup checks, periodic restore tests, certificate renewal and patching. Upgrades follow the version skew policy: the kube-apiserver moves one minor version at a time, before the controller manager, scheduler and kubelets, and kubelets may be up to three minor versions older than the API server. The Kubernetes project maintains the three most recent minor releases, and as of September 2026 these were 1.37, 1.36 and 1.35, so plan for at least one upgrade cycle per year. Ask any provider for written runbooks, the scope of support in writing, and confirmation that your team holds administrative access after the engagement ends.
Which control frameworks apply to a government Kubernetes cluster?
The applicable framework depends on the data and the agency. Federal systems commonly map to NIST SP 800-53 Revision 5, where the low, moderate and high baselines in SP 800-53B select 149, 287 and 370 controls and enhancements respectively, in the current Release 5.2.0. Systems handling criminal justice information follow the FBI CJIS Security Policy, and version 6.1 requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for that data in transit and at rest outside physically secure locations. Contractors handling controlled unclassified information look to NIST SP 800-171 through 32 CFR 2002.14. Cluster controls such as network policies, RBAC, audit logging and encryption at rest map to several of these controls. Confirm with your authorizing official which framework and baseline govern your system before the build starts.
How DeployOpen scopes and delivers agency Kubernetes platforms
DeployOpen plans, builds, hardens, documents and supports self-hosted Kubernetes inside the agency's own infrastructure, including air-gapped networks where a private registry replaces public image pulls. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm whether the cluster runs connected, air-gapped or in a mixed network, since this changes image sourcing and patch flow
- Record the chosen distribution, its CNCF conformance status and the Kubernetes minor version it will run
- Agree the identity source, RBAC model and whether Pod Security Standards are enforced per namespace
- Identify which Kubernetes APIs, ingress and controllers the workloads depend on and any retired mechanisms to replace
How we build
- Build the control plane as a stacked or external etcd topology with at least three control plane nodes behind a TCP load balancer on port 6443
- Mirror control plane and add-on images to a private registry and use the kubeadm image repository setting for installs without internet access
- Enable encryption at rest for Secrets and apply least-privilege RBAC for list and watch access
- Configure API server audit logging and test that events reach the agency's log store before handover
How we hand over
- Document the cluster build as delivered, including topology, registry mirror, identity configuration and network boundaries
- Provide a hardening report mapped to the CIS Kubernetes Benchmark sections agreed in scope, with documented deviations
- Run and record an etcd snapshot backup and a restore test in a non-production environment
- Hand over runbooks for upgrades following the version skew policy, plus a named list of owners for each operational task
How we support
- Offer ongoing support, upgrades and testing as a retainer, with the service levels stated in the signed agreement
- Plan minor version upgrades one step at a time, starting with the API server, using the version skew limits
- Track Kubernetes patch releases and review them against the agency's approved change process before rollout
- Ask for the retainer scope, response expectations and upgrade cadence in writing before committing to a support model
