Why Kubernetes for financial services needs a regulated build from day one
For a bank or payment firm, the Kubernetes cluster is in scope for controls, evidence and resilience before the first workload moves onto it. The platform team running the cluster in its own cloud accounts or data centers carries the same accountability as the team running the card data environment, because PCI DSS applies to any system that could affect the security of cardholder data. Kubernetes is licensed under Apache 2.0, which lets your team choose, run and modify the distribution itself. That freedom also means no regulated defaults arrive with the software, so every security decision in the build is one your team has to make and document.
Three areas need deliberate configuration before any payment service is deployed. The first is the control plane. Follow the kubeadm high availability guidance: choose a stacked or external etcd topology, run at least three control plane nodes, and place a TCP load balancer in front of kube-apiserver on port 6443. The second is etcd itself. It should run an odd number of members, and the Kubernetes documentation recommends five members in production. Plan snapshot backups with etcdctl snapshot save, and test restores with etcdutl in a separate environment. A backup that has never been restored is not yet evidence of resilience.
The third area is identity and secrets. Kubernetes does not store normal users as API objects, so you must decide how people authenticate. Options include X.509 client certificates, OpenID Connect or JWT bearer tokens, webhook token authentication and authenticating proxies. Map the chosen option to your identity provider and to a documented process for removing administrator access. Secrets are stored unencrypted in etcd by default, so encryption at rest must be enabled, list and watch access on Secrets must be limited through least-privilege RBAC, and your team should decide whether an external store through the Secrets Store CSI Driver fits your key management model.
The standard the cluster will be measured against is PCI DSS v4.0.1, the only active version since v4.0 retired on 31 December 2024. The 51 future-dated v4.0 requirements took effect on 31 March 2025, so a cluster designed now should meet them from the start. The PCI Security Standards Council does not enforce compliance. The payment brands decide which entities must validate and run any enforcement, and validation is documented in a Report on Compliance by a Qualified Security Assessor or in a Self-Assessment Questionnaire, each with an Attestation of Compliance. DeployOpen prepares systems, controls and evidence for that assessment, but independent assessors issue the attestation.
DeployOpen plans and builds these pieces inside your infrastructure. Before construction starts, settle three decisions: which conformant distribution your team will operate, which Kubernetes minor version to start on given the published support windows, and how each control will be evidenced for your assessor. The CNCF conformance program checks that a distribution supports the required Kubernetes APIs and lists over 90 certified offerings, so conformance is a starting filter that says little about hardening. Ask your partner to map Pod Security Standards to each namespace and to confirm the support dates for your chosen version on the Kubernetes releases page before the design is signed off.
Which financial rules shape the cluster design, and what each means for the build
This table maps six financial rules to their source and to the cluster decision each one drives. Read each row left to right: the first column names the source, the second describes what the rule asks for, and the third shows the design choice or evidence it leads to. The main takeaway is that several rules need the same artifacts, including access controls, reviewed change records and documented exit paths, so design them once for all of them.
| Rule and source | What it asks for | What it means for the build |
|---|---|---|
| PCI DSS v4.0.1 (PCI SSC) | Defines the cardholder data environment and 12 principal requirements. v4.0.1 is the only active version. | Place the cardholder data environment in dedicated namespaces and node pools, enforce network policies, and test segmentation before assessment. |
| DORA Article 28(3) and 28(8), Regulation (EU) 2022/2554 | A register of all ICT contracts, and documented, tested exit strategies for services supporting critical or important functions. | Record the cluster and its vendors in the register, and keep a tested plan for moving workloads off the platform. |
| DORA Article 30(2) | Contracts state where services are provided and data processed, with advance notice of changes and data return on termination or insolvency. | Name cluster hosting, backup and registry locations in contracts, and write data return and change notice into hosting and support terms. |
| Swift Customer Security Controls Framework v2026 | 32 controls, 26 mandatory and 6 advisory, independently assessed and attested annually in the KYC-SA application. | Map cluster hardening, access and logging settings to each applicable control, and keep configuration evidence an assessor can review. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. | Require SSO with MFA for kubectl, dashboards and GitOps tools, and file any written exception approved by the Qualified Individual. |
| SEC Release 33-8810 (SOX 404 ICFR guidance) | Names program development, program changes, computer operations and access to programs and data as IT general control areas. | Route manifest changes through reviewed pull requests, limit cluster-admin rights, and retain deployment and access logs for auditors. |
Which cluster settings carry the most weight for a payment environment
Six cluster settings determine whether a payment environment on Kubernetes can be segmented and evidenced. Each card covers one control plane, data, access or logging decision and the checks that show it works in your distribution. Confirm each setting against the distribution you choose, because installers differ in what they configure by default.
Control plane and etcd topology
Three or more control plane nodes behind a TCP load balancer on port 6443 remove the API server as a single point of failure for cardholder workloads. The kubeadm high availability guide describes a stacked topology, where etcd runs on the control plane nodes, and an external etcd topology. Where the design calls for external etcd, the Kubernetes documentation recommends five members and an odd member count so the cluster keeps quorum when one member fails. Confirm which topology your distribution uses and whether its installer builds the load balancer for you.
Secrets encryption at rest
Kubernetes stores Secrets unencrypted in etcd by default, so payment credentials, API keys and TLS private keys are readable by anyone with direct access to etcd data. Configure encryption at rest for Secrets through the API server encryption configuration, and hold the key material under your key management controls outside the cluster. For card-related credentials that should never sit in etcd, consider an external store through the Secrets Store CSI Driver. Confirm whether your distribution exposes the encryption configuration and how key rotation is performed.
OIDC authentication and least-privilege RBAC
OpenID Connect ties kubectl and API access to your identity provider, so access follows your joiner and leaver process. Pair it with least-privilege RBAC, because list and watch verbs on Secrets or Pods expose every object of that kind in a namespace, and cluster-wide bindings expose them everywhere. Bind roles to identity provider groups, review CI service account and operator roles for list and watch, and document a break-glass path for when the identity provider is unavailable. Confirm your distribution's OIDC claim mapping and whether it installs its own cluster-admin bindings.
Pod Security Admission per namespace
Pod Security Admission enforces the Privileged, Baseline or Restricted Pod Security Standard on each namespace through labels. Set Restricted enforcement on cardholder data namespaces, and keep privileged workloads such as CNI or storage daemons in separate system namespaces with documented exceptions. Run warn and audit modes on new namespaces before enforcing, so teams see violations first. Confirm that the distribution does not apply a privileged default to pods in the CDE, and that no third-party admission webhook overrides the built-in controller.
Network policies around the CDE
Network policies enforce segmentation inside the cluster, but only when the CNI plugin implements them, and some plugins do not. Apply default-deny ingress and egress to CDE namespaces, then allow only the flows your payment service map documents, such as the payment API to the tokenization service and database. Test blocked paths from an untrusted namespace and keep the policy manifests and test results as segmentation evidence. Confirm that your CNI enforces NetworkPolicy before relying on any of it.
Audit logging for evidence
Kubernetes audit logging records each API server request, including who made it, what it targeted and how the server responded. Define an audit policy that captures Secrets access, RBAC changes, exec and port-forward sessions and namespace label changes, then send events to a log store the security team controls. Retention and integrity matter as much as capture, because assessors will ask for evidence covering a defined period. Confirm the policy file format your distribution accepts, the log backend it ships with, and who can modify or delete the logs.
How network policies and namespaces define PCI DSS scope in a cluster
Network policies and namespaces do not set PCI DSS scope on their own, but they are the tools that let you draw the boundary inside a cluster. Scope follows the cardholder data environment (CDE) and any system that could affect the security of that environment. The design starts by listing which workloads store, process or transmit cardholder data, which workloads connect to them, and which workloads have no path to them at all. Write that map down before the first namespace is created, because each line of it becomes a segmentation decision. Treat the map as a living document that changes whenever a service is added, moved or connected to a payment flow.
Namespaces organize objects and give RBAC a scope, but pods in different namespaces can still reach each other until network policies say otherwise. Place CDE workloads in dedicated namespaces, or in a dedicated cluster when your risk assessment and assessor expectations call for it, and apply a default-deny policy to ingress and egress in each one. Then add explicit allow rules for each required flow, such as the payment service to its database, the ingress controller to the API and DNS lookups. Confirm that your CNI plugin enforces NetworkPolicy, because a policy object the network layer ignores gives false assurance. Pair this with Pod Security Admission set to the Restricted Pod Security Standard on CDE namespaces, which limits what a compromised pod can do to the host.
Shared services are where most scope discussions start. DNS, the ingress controller, a service mesh, log shippers, monitoring agents and a secrets store often run cluster-wide, and any of them that can reach CDE pods or read their data becomes part of the scope question. Decide for each one whether it runs as a dedicated instance for the CDE, whether it stays out of the CDE network path, or whether it is accepted into scope and controlled as such. Access control matters as much as traffic rules. Anyone who can edit NetworkPolicy objects, change namespace labels or list and watch Secrets in CDE namespaces can alter the boundary, so limit those roles with least-privilege RBAC and review them against audit logs.
Before go-live, ask your Qualified Security Assessor or internal assessor how segmentation will be tested, because the answer determines what evidence the cluster must produce. Ask which method they accept, how often they expect testing, whether they want testing from inside the CDE and from outside it, and how they treat node networks, the API server and etcd when they share infrastructure with the cluster. Confirm whether they expect a separate cluster per scope level or accept namespace isolation. The cluster does not reduce PCI DSS scope on its own. The PCI DSS v4.0.1 requirements on testing security systems and processes cover segmentation, so plan to repeat that testing after any policy change that touches a payment flow.
How a financial services Kubernetes rollout moves from scoping to production
This sequence takes a financial services Kubernetes platform from a scope agreed with the assessor to a production cluster with identity, hardening, segmented workloads and an upgrade plan. Each phase closes with a written record or a test result, so the assessor and the operations team can trace every control to its evidence.
Scope the cardholder data environment with the assessor
DeployOpen and your assessor agree which clusters, namespaces, nodes, registries, identity sources, logging paths and administrative workstations fall inside the PCI DSS v4.0.1 scope. Together you map data flows: where cardholder data or sensitive authentication data enters, is stored, processed or transmitted, and which connected services could affect its security. Confirm early whether the validation route will be a Report on Compliance or a Self-Assessment Questionnaire, because that choice sets the evidence you must collect. The step is complete when the scope statement and data-flow diagram are signed by your security owner and the assessor, and each boundary has a named control owner.
Choose the distribution and offline image path
Select a Kubernetes distribution that passes CNCF conformance testing and supports the API set your workloads need. Then decide how images reach the clusters. If the clusters have no outbound internet access, kubeadm can list and pull the control plane images, and the --image-repository option points kubeadm init at your private registry. Record the mirroring process, the image signing and scanning steps, and the minor version you will run, checked against the project's published end-of-life dates. The step closes with a distribution decision record and an image manifest that matches the chosen Kubernetes version.
Build the control plane with HA and etcd
Choose a stacked or external etcd topology using the kubeadm high availability guide as the baseline. The guide calls for at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Kubernetes documentation says etcd should run with an odd number of members and recommends five members in production, so confirm the member count with your operations team. Set up snapshot backups with etcdctl snapshot save and rehearse a restore with etcdutl on a separate environment. The step closes when a control plane node can be removed in a test without losing API access and a restore from snapshot has been completed and recorded.
Connect identity and define RBAC roles
Kubernetes does not store human users as objects. It authenticates them with X.509 client certificates, bearer tokens such as OpenID Connect and JWT, webhook token authentication or an authenticating proxy. Connect the cluster to the identity provider your organization already operates, and keep a small set of break-glass accounts with documented custody. Define RBAC roles on least privilege, grouping permissions by job function and namespace. Restrict list and watch access to Secrets, since those verbs expose secret values. The step closes with an access matrix that maps each role to its groups, plus tests showing that each role is denied the actions it should not hold.
Harden the cluster against the CIS Kubernetes Benchmark
Run a configuration assessment against the CIS Kubernetes Benchmark for your Kubernetes version and the distribution you chose. The benchmark is a consensus guide, so each finding needs a decision: remediate it, or document why a deviation is acceptable and who approved it. Turn on encryption at rest for Secrets, because Kubernetes stores them unencrypted in etcd by default. Apply Pod Security Standards per namespace through Pod Security Admission, and configure audit logging for API requests. The step closes with a benchmark report that lists every finding, its disposition and the approver, with the remediation evidence attached.
Onboard workloads into segmented namespaces
Group workloads by data classification and by whether they touch the cardholder data environment, then place each group in its own namespace. Apply default-deny network policies so that only the flows in your data-flow diagram are permitted, and set Pod Security levels, with Restricted as the target where the workload allows it. Limit which registries images can come from, and decide how each workload gets its secrets, either from encrypted Kubernetes Secrets under strict RBAC or from an external store through the Secrets Store CSI Driver. The step closes with an onboarding checklist per workload and a test run that shows blocked paths are blocked and required paths still work.
Run operations and set the upgrade cadence
Operations takes over with runbooks for backups, restores, node replacement, certificate rotation, audit log review and incident response. Schedule etcd snapshots and repeat the restore rehearsal on a defined cadence. Kubernetes publishes roughly three minor releases a year on a cycle of about 14 weeks, and the project supports the three most recent minor versions, so plan an upgrade calendar against those dates. Follow the version skew policy: upgrade kube-apiserver one minor version at a time, before controller-manager, scheduler and kubelets, and keep kubelets no more than three minor versions behind. The step closes with an approved upgrade calendar, a rehearsed upgrade on a non-production cluster and a named owner for each runbook.
Which frameworks apply to a payment or banking cluster, and how the cluster supports each
Which frameworks apply depends on your entity type, the regulator with jurisdiction and the services you provide, so confirm the applicable set with counsel and your assessors before you scope the cluster. The cards below cover five frameworks that often shape payment and banking platforms. Each card states what the cluster can evidence and which obligations remain process or contract matters outside it.
PCI DSS scope and approach
PCI DSS v4.0.1 applies to entities that store, process or transmit cardholder data, or that could affect the security of that environment, and the payment brands decide who must validate. Segmentation with network policies, dedicated namespaces and separate node pools defines the cardholder data environment, so scope follows design choices you can test. Each requirement can be met through the defined approach or, for entities with mature security and risk management, the customized approach. Agree the scope and the approach with your QSA before you finalize the cluster design.
DORA register and contract clauses
DORA has applied since 17 January 2025 to 20 types of financial entity, including credit and payment institutions. Article 28(3) requires a register of information on all contractual arrangements for ICT services, and Article 30(2) requires each ICT services contract to state where services are provided and data processed. For the cluster, record every distribution, cloud, registry and support provider in the register, and check that contracts cover data return on termination. Confirm with counsel whether your entity is in scope.
Swift CSP attestation for connected users
The Swift Customer Security Controls Framework v2026 has 32 controls, 26 mandatory and 6 advisory. Connected Swift users must have these controls independently assessed and attest compliance each year in the KYC-SA application. The cluster contributes evidence for controls that apply to the environment hosting a Swift connector, such as restricted administrative access, hardened runtime settings and logs showing who changed what. Ask your assessor which controls depend on that environment.
FTC Safeguards multi-factor authentication
The FTC Safeguards Rule (16 CFR Part 314) applies to non-bank financial institutions under FTC jurisdiction and requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. In the cluster, this covers human access to the Kubernetes API, GitOps consoles, dashboards and secrets tooling. Federate these through your identity provider using OpenID Connect, enforce MFA there, and keep any written exception on file.
SEC ICFR IT general controls
SEC guidance in Release 33-8810 names program development, program changes, computer operations and access to programs and data as example IT general control areas for SOX Section 404 assessments. In the cluster, this means change records tied to Git commits and reviews, RBAC limited to named roles, audit logs of API activity, and documented scheduling for backups and batch workloads. Confirm with your auditor whether your reporting status brings these assessments into scope.
What a payment firm should decide before choosing a distribution
The distribution you choose sets the terms for everything that follows, so settle four questions before you shortlist vendors. The first is conformance. The CNCF Certified Kubernetes conformance program checks that a distribution supports the required Kubernetes APIs, and the CNCF page states there are over 90 certified offerings. Conformance confirms the API surface. It does not confirm the vendor's patches, bundled add-ons or default settings, which determine how your cardholder data environment behaves. Ask for the conformance listing for the exact minor version you plan to run, and confirm in writing that the add-ons you intend to use are covered by that listing.
The second decision is the support lifecycle. The Kubernetes project maintains only the three most recent minor releases, and each receives about one year of patch support. A distribution vendor may offer a longer or shorter window, and may backport security fixes on its own schedule. Request a table of end-of-support dates for each minor version, the vendor's target time from an upstream fix to a shipped patch, and the policy for critical CVEs. Compare those dates with your PCI DSS patching obligations and your upgrade cadence, keeping in mind that the version skew policy requires kube-apiserver to move one minor version at a time, ahead of the other control plane components and the kubelets.
The third decision is hardening defaults, because a fresh cluster is not a compliant one. Kubernetes stores Secrets unencrypted in etcd by default, so confirm whether the distribution configures encryption at rest, which key provider it uses, and how keys are rotated. Check whether Pod Security Admission is enabled, which Pod Security Standard level applies to default namespaces, and whether audit logging ships with a policy you can review. Then check CIS Kubernetes Benchmark coverage for your platform: which benchmark version the vendor targets, which sections its hardened profile addresses, and which controls it leaves to you. Treat any coverage claim as a statement to verify by running the benchmark checks yourself.
The fourth decision is contract terms for hosting location and data return. DORA Article 30(2) requires ICT service contracts to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination of the provider. Article 28(8) asks for documented and tested exit strategies where ICT services support critical or important functions. Ask the vendor to name the locations for support access, telemetry, backups and any remote administration, to commit to notice periods for changes, and to specify the format and timing of data return. Whether DORA applies to your firm depends on your entity type, so confirm that with counsel before you rely on it.
Questions banks and payment firms ask before hiring help with Kubernetes
What drives the cost of a self-managed Kubernetes build for a bank?
Cost follows scope. Kubernetes is open source under the Apache 2.0 license, so most of the spend is people and infrastructure: design, build, integration, testing and documentation. The largest drivers are the number of clusters, the control plane topology (kubeadm's high availability guide describes stacked and external etcd layouts, with at least three control plane nodes behind a TCP load balancer), identity integration, air-gapped installation, the number of workloads moving onto the platform and how much evidence your assessor will need. Recurring costs include patching and upgrades, because Kubernetes releases arrive about three times a year and each minor version receives roughly one year of patch support. Ask any quote to separate one-time build work from recurring support and retainers.
How long does a Kubernetes build for a regulated firm take?
No single duration applies, because the timeline depends on scope, infrastructure readiness and approvals. Most engagements are fixed-scope, and the schedule is agreed in writing before work starts. The usual pauses come from cloud or data center account provisioning, private registry setup, the identity provider decision, change approval windows, security testing and collecting evidence for assessors. Ask for a milestone plan that shows dependencies on your side, named review gates and what happens if an input arrives late. Also plan for what follows go-live: with minor releases roughly every 14 weeks, the platform will need regular upgrades, so the schedule should include a first upgrade window.
What does our internal team need to provide for a Kubernetes engagement?
Expect to provide named decision-makers, infrastructure access and owners who will run the cluster after handover. In practice that means network design and the firewall change process, cloud or data center accounts with the access the build requires, the identity source (such as an LDAP directory or OpenID Connect provider) and the groups that will map to RBAC roles, the chosen distribution and Kubernetes version, access to a private registry if the environment has no internet access, security reviewers for admission and network policies, and a data classification for each workload. Ask the quote to list each input, its owner and the date it is needed. Clear ownership at the start makes the rest of the plan easier to hold to.
Can our own platform team build and run a self-managed Kubernetes cluster?
Yes, many platform teams can, provided they have solid Linux, networking, certificate and storage skills and time to learn the upgrade cycle. The Kubernetes project publishes documentation for high availability clusters and for clusters without internet access, so the build path is documented. The harder parts for a regulated firm are etcd backup and restore practice, RBAC and admission policy design, audit log retention, encryption at rest for Secrets and producing evidence that each control works. Test your capacity against the version skew rules, which require the kube-apiserver to move one minor version at a time before other components. A common split is for your team to run operations while an outside team handles the build, hardening or an independent review.
How do we keep PCI DSS scope small when Kubernetes runs payment workloads?
Scope is set by where cardholder data is stored, processed or transmitted, and by any system that could affect the cardholder data environment. Keep payment workloads on dedicated clusters or node pools where that is practical. Network policies can restrict traffic between namespaces, but they only help when the cluster network enforces them and the segmentation is tested rather than assumed. Other levers include separate namespaces with the Restricted Pod Security Standard where workloads allow it, least-privilege RBAC, encryption at rest for Secrets with an external store where needed, a separate administrative identity boundary and log pipelines that feed a controlled store. Confirm the boundary with your Qualified Security Assessor before the design is frozen, because the assessor decides what is in scope for your environment.
What does a fixed-scope Kubernetes quote from DeployOpen cover?
A fixed-scope quote covers the work listed in the written scope: the agreed deliverables, timelines, assumptions and exclusions, all confirmed in writing before work starts. For a Kubernetes build this usually names the distribution and version, the control plane topology, identity integration, hardening against the CIS Kubernetes Benchmark, etcd backup and restore procedures, documentation, handover and any testing included. DeployOpen does not publish a price list, so the quote follows from that scope. Ask whether the quote states which environments are covered, what your team provides, what is excluded (such as application migration or external audits), the acceptance criteria, how change requests are priced and whether ongoing support or upgrades are a separate retainer. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or attestations.
How should etcd be backed up and restored in a financial Kubernetes cluster?
Run etcd with an odd number of members, and use five members in production as the Kubernetes documentation recommends. Take regular snapshots with etcdctl snapshot save, store them away from the control plane nodes in an encrypted location with access logging, and keep the restore path tested with etcdutl. Etcd holds Secrets, which are stored unencrypted by default, so configure encryption at rest before relying on those backups. Back up the encryption keys separately, because a snapshot cannot restore encrypted Secrets without the key. A stacked topology shares nodes between etcd and the control plane, while an external etcd cluster separates them. Test restores on a separate cluster at a cadence your recovery objectives require, time each step, and document who can authorize a restore during an incident.
Who signs off PCI DSS compliance for a Kubernetes environment?
The payment brands decide which entities must validate, and the PCI Security Standards Council does not enforce compliance itself. Validation is documented either in a Report on Compliance written by a Qualified Security Assessor or in a Self-Assessment Questionnaire, and each ends with an Attestation of Compliance. Certificates are not accepted as validation. DeployOpen does not issue reports, attestations or certificates. What it can do is plan and configure the Kubernetes controls, document them and prepare evidence for your assessor, such as RBAC configuration, audit log samples, network policy definitions and backup restore records. Before design starts, confirm with your acquirer or assessor which PCI DSS version and approach apply to your environment. PCI DSS v4.0.1 is the only active version.
How DeployOpen scopes and delivers a regulated Kubernetes platform
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kubernetes in financial services, we start from the segmentation, audit logging, encryption and resilience expectations your cardholder and critical services need, then build and hand over a cluster your team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope names which environments, clusters and workloads fall inside the cardholder data environment and which sit outside it
- Scope records the Kubernetes distribution, identity provider, registry and infrastructure you already run, so the design fits your estate
- Ongoing support, upgrades and continuous testing can be added as a retainer, priced separately from the build
How we build
- Network policies are designed to segment payment workloads from other namespaces, then tested with traffic that should be blocked
- Secrets encryption at rest is configured for etcd, and access to Secrets is limited by least-privilege RBAC
- Pod Security Admission levels are set per namespace, with Restricted as the target where workloads allow it
- Control plane high availability follows the kubeadm topology you choose, with etcd backups taken by snapshot and restore steps rehearsed
How we hand over
- Documentation covers the architecture, network policy map, RBAC model, audit log locations and encryption configuration
- Compliance evidence is prepared as artifacts your assessor can review, for example configuration exports and test results, without DeployOpen issuing any attestation
- Runbooks cover upgrade stops under the version skew policy, etcd restore, certificate rotation and incident response for the cluster
- Knowledge transfer sessions are planned with your platform, security and operations staff before handover is accepted
How we support
- Support covers patching of the chosen distribution, scheduled minor version upgrades and review of Kubernetes release notes for your clusters
- Periodic security testing of applications, APIs and cluster configuration can be scoped alongside the platform
- Changes to network policies, RBAC or admission rules go through your change process, with DeployOpen documenting each change
- Retainers are agreed in writing, with the response and review cadence stated in the contract
