Managed Kubernetes Responsibility Matrix for Production Teams

Who owns what in managed Kubernetes

Five parties share ownership in a production Kubernetes engagement, and the boundary between provider and customer runs along one line: the provider owns the control plane and the infrastructure beneath it, and you own what runs inside the cluster. The provider secures every control-plane component. You own cluster workloads and the policies that govern identity and networking.

That clean split is exactly where the cost shows up. The same Red Hat research found that 74% of teams are actively delaying deployments because their internal developers are stuck manually triaging cluster configuration drift and security gates instead of shipping product. The provider carrying the control plane concentrates your exposure: the parts a provider cannot touch, RBAC design and policy intent, are exactly the parts that break clusters in production and stall releases. This is where a Managed DevOps partner bridges the gap between infrastructure ownership and operational security.

The five parties in a responsibility matrix

A production matrix has five actors. The cloud provider runs the managed control plane and the physical estate. The external operator or managed service partner handles day-two operations the provider leaves untouched. Your platform team owns cluster configuration and the internal developer surface. Your security team owns policy intent and evidence. Your application teams own what they ship and its reliability.

Each party owns what it is structurally best placed to own. The provider is closest to the hardware and the API machinery. Your security team is closest to your risk appetite and your auditors.

Grouped by risk rather than by component, the picture sharpens. The cloud provider and your application teams carry comparatively contained risk; one is standardized across vendors, the other is scoped to a single service. The real exposure concentrates in the three columns in between, and the External Operator column is the most consequential of them, because when it's empty, it collapses onto whichever internal team is left standing. If you have no external operator or MSP, your internal platform team absorbs 100% of the Day-2 operational load: zero-day patching, node hardening, upgrade coordination, on top of the product features they were already hired to ship. That's the gap of liability a five-party diagram can hide and a risk-ranked one can't.

The CyberDefenders analysis of Kubernetes-as-a-Service found that most KaaS incidents trace to the customer's side of the responsibility line. That distribution tells you where to concentrate your matrix. Three of the five parties are inside your own walls, so most of the ownership you are assigning never leaves the building, no matter how heavily you outsource.

What does the cloud provider own

The cloud provider owns data-center security and the managed control plane, including its availability and patching. That includes control-plane services and the physical and environmental security of the facilities hosting them.

This baseline is nearly identical across Amazon Elastic Kubernetes Service (EKS); Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE) follow the same model. ARMO's breakdown of the shared responsibility model confirms the provider secures the control plane and the infrastructure-level components across all three managed services.

That baseline is the old "shared responsibility" logic: the provider secures its side of the line, and if you misconfigure RBAC on yours, that's on you. Google Cloud has spent the last couple of years pushing the industry toward a different model it calls "shared fate", where the provider takes an active role in preventing customer-side misconfigurations instead of waiting for them to cause an incident. Kubernetes is complex enough that most organizations need an operating partner like ABS Technologies, which treats misconfiguration monitoring as a continuous, shared obligation rather than a dashboard it hands you and calls done.

Because this layer is standardized, it is the part of your matrix you can copy between clouds without editing. Where the matrix starts to diverge is one layer up, at the node, and that is where your team re-enters the picture.

What does an external operator add

An external operator covers the day-two operations the raw cloud provider leaves on your plate. That means node operations and add-on lifecycle, with responsibility extending to upgrade coordination and the tooling for observability and incident response. The operator fills the gap between the provider's control plane and your workloads.

Treat this as a distinct column that differs from the cloud provider. The provider gives you a managed control plane and walks away from your kubelets. The operator picks up there.

The CNCF 2025 Annual Survey found that 82% of container users run Kubernetes in production, which makes the operational load this column absorbs a mainstream problem. If you have no operator, your platform team absorbs this column, and your matrix has to show that honestly.

What stays with your internal teams

Internal teams retain identity design and network policy intent. They also retain application reliability and compliance evidence, while image provenance decisions stay internal even under a heavy outsourcing arrangement. An operator can execute these, but the intent behind them is yours.

The reason is structural. A partner does not know which service accounts should reach which secrets, or which data your regulator classifies as sensitive. The Wiz academy guide on the shared responsibility model stresses that teams must document OS responsibilities clearly to avoid drift and missed patch cycles, and the same logic applies harder to identity and policy.

So the more you outsource execution, the sharper your ownership of intent has to become, because you are now directing work you no longer do yourself. That distinction between intent and execution is the spine of the non-transferable section later in this article.

Mapping every Kubernetes responsibility to an owner

The practical core of the matrix is a line-by-line assignment of a primary owner and supporting parties for every production responsibility. This is the reference section you will return to, so it names the component and the owner without redefining what the component is.

Here is the full production list this section walks through:

• Provisioning, control-plane upgrades, and node operations

• Network policy, ingress, and the identity and access model

• Secrets management, image provenance, and admission control

• Observability, backup, and recovery

• Capacity planning, cost governance, incident response, and application reliability

Red Hat's data puts 45% of Kubernetes incidents down to misconfigured settings, which serves as a live attack surface. Research from Wiz shows new clusters face their first attack attempt within 18 minutes of deployment, and campaigns like "RBAC Buster" show what happens next: attackers exploit an exposed API server, grant themselves a malicious ClusterRole, and quietly run cryptojacking operations for months. Misconfiguration is a symptom of unclear ownership more than weak tooling. When two parties each assume the other configured a NetworkPolicy and leave that row to an internal team that's also shipping features on the same sprint, that's how a cluster stays exposed long enough for that 18-minute window to matter. Here's a named primary owner for each row, which is the artifact that closes the gap an auditor and an attacker will otherwise find.

Provisioning, upgrades and node operations

Provisioning and control-plane upgrades sit with the provider. Your platform team determines version selection and upgrade timing, then validates workload compatibility and configures node pools. The provider ships the new minor version. You decide when to take it and whether your workloads survive it.

Upgrade timing is a business decision wearing an operational costume. Miss the window and you pay six times the rate for a cluster the provider still technically manages, which is the clearest proof that provider ownership of the control plane does not mean provider ownership of your upgrade calendar.

Networking, ingress and identity

The provider supplies the networking substrate and the RBAC engine, while your team designs and owns network policy intent along with ingress and identity access models. Kubernetes gives you the mechanism. You supply the rules.

These are design responsibilities that cannot be delegated wholesale. By default, every pod in a cluster can reach every other pod. The Lorikeet Security analysis of segmentation testing notes that a non-CDE workload has unrestricted network access to a CDE workload in the same cluster unless NetworkPolicies are explicitly configured.

That default is the trap. A provider hands you a cluster that is open internally and calls it done, because closing it requires knowing your architecture. So when your matrix marks network policy as shared, the intent cell must still read as yours, or the flat network the provider shipped becomes the lateral-movement path an attacker uses.

Secrets, images and supply chain

Secrets management and image provenance are shared between your platform and security teams. Registry controls and admission policy are also shared between those teams. Application teams own what they actually ship. The platform team runs the registry and the admission controller. The security team sets the policy those controls enforce.

Supply-chain findings cluster here. According to Wiz 2025 data, 85% of container images in production carry high or critical vulnerabilities, which lands squarely on the application-team side of this row.

That number reframes admission control from a nice-to-have into the enforcement point that catches what your developers cannot. If most images arrive vulnerable, the policy gate your platform and security teams own is the last place to stop them before runtime, so the shared cells in this row are doing more work than any single-owner row in the matrix.

Observability, backup and recovery

The provider or operator supplies tooling and cluster-state backup. You own backup policy and application-level observability, and you validate restores. A backup feature is not a backup guarantee.

This distinction concerns operational responsibilities. Untested backup is an unverified backup.

So the row for recovery has a hidden second cell. The provider owns snapshot creation. You own the proof that the snapshot restores into a working cluster, because only a completed restore test tells an auditor your recovery objective is real. When your matrix marks backup as provider-supplied, the validation column beside it has to name your team, or you are documenting a capability you have never confirmed works.

Capacity, cost and application reliability

Capacity planning and cost governance stay internal regardless of provider, and application reliability is always owned by the application teams. No managed platform absorbs these because they depend on your own capacity and cost decisions.

Cost governance is heavier than the sticker price suggests. That gap between projected and real cost is a governance responsibility. A provider will happily scale your cluster and invoice the result. Owning the FinOps view of that spend is yours, which is why capacity and cost sit in internal columns that never migrate outward no matter how much operational work you hand off.

How do EKS, AKS and GKE change the lines?

The fully managed tiers push more of the node and hardening layer to the provider, while the Standard tiers return responsibility for node configuration. Your platform team also takes OS hardening and upgrade sequencing. The amount of data plane that crosses the line varies by service tier.

They do not move the same amount. The New Stack's deep dive found that AKS Automatic automates control-plane and nodepool updates, while EKS Auto Mode automates node version updates but still requires manual intervention for control-plane upgrades.

So you cannot maintain one matrix across all three and call it accurate. GKE Autopilot lets you delete several node-level rows entirely, because it manages the full node lifecycle and applies hardening by default. EKS Auto Mode leaves the control-plane upgrade row firmly in your column even while it takes the nodes. Adjust the matrix to the tier you actually run because the tier decides which rows you keep.

What changes for self-managed clusters

Self-managed clusters return control-plane provisioning and etcd operations to your internal columns. They also return high availability and patching. Every row a managed provider owned is now yours. This includes hardening the components you never had to touch before.

The weight of that reabsorption is measurable. The current CIS Kubernetes Benchmark includes 131 recommendations in version 1.12, and a large block of those applies to the control plane that a managed provider previously handled for you.

That is the true cost of leaving managed Kubernetes, and it rarely shows up in the migration business case. You are taking ownership of roughly seventy control-plane hardening controls. You must also maintain their evidence and patch cadence; this work was invisible because someone else did it. Before you reabsorb it, your matrix should show every one of those rows flipping from provider to internal, so the decision is made with the real headcount in view.

Which responsibilities can never be outsourced?

Accountability for identity design and data classification can never be transferred. The same applies to compliance evidence and to responsibilities for network policy intent and application reliability. Only the execution of these can be shared. A partner can configure your RBAC, but the decision about who should have access, and the answer you give an auditor, stays with you.

This corrects a dangerous and common assumption that a managed provider absorbs liability. The industry consensus is that when a managed cluster is breached, the finding lands on you, because the misconfigured control was on your side of the line. The point of naming non-transferable responsibilities is to make sure that when you outsource execution, your matrix still shows your name in the accountable column, because that is the column the regulator reads first.

Turning the matrix into an auditable RACI

Convert ownership into a defensible document by assigning Responsible, Accountable, Consulted, and Informed across the five parties. Attach required evidence to each responsibility and define escalation paths for crossed boundaries. A diagram shows who owns what. A RACI shows who answers for it.

The critical rule is that every responsibility has exactly one Accountable party, even when several are Responsible for execution. Shared execution with unclear accountability is precisely the condition that produces the misconfiguration rate we have already seen, where each party assumes another acted.

The Pomerium guide to Kubernetes compliance maps concrete controls to PCI DSS Requirement 1 network segmentation through NetworkPolicies, which shows how a single matrix row expands into a specific, testable control. That is the move that makes a RACI auditable. Each row stops being a label and becomes a control with a named owner and a piece of evidence attached, which is the form an auditor can actually accept.

What evidence proves each responsibility?

Each responsibility is proven by a specific artifact. Lifecycle rows use upgrade logs, while identity uses RBAC audit exports. Recovery uses restore-test results, and admission and network control use policy reports. The evidence type is tied to the owner, so the artifact and the accountable party appear in the same row.

Evidence is where audits are won or lost. That mapping also tells you which evidence you cannot produce yet. If a row names an owner but no artifact, that is an audit gap you can see before the auditor does, which is the entire reason to attach evidence at design time instead of scrambling for it during the review.

How do escalation paths work?

Every shared responsibility needs a named accountable party and a defined escalation path across all involved teams and the provider. During an incident with an unclear boundary, the escalation path decides who acts.

The incident-response RACI is the model. The New Stack found that EKS Auto Mode still requires manual intervention for certain control-plane tasks, which means an incident touching that layer has to escalate cleanly to the provider through a pre-agreed route.

The practical test of an escalation path is whether it names a person or a ticket queue at each hop. An incident that crosses the provider boundary without a defined handoff stalls exactly where your matrix went vague, so the escalation column is where you convert ownership into response time.

Extra controls for regulated workloads

Regulated workloads require documented role assignment and continuous monitoring ownership. They also require stricter evidence retention and formal separation among the relevant functions. A matrix that satisfies internal clarity is not enough when a framework like PCI DSS is the audience.

Segmentation carries specific weight here. Microsoft's AKS regulated-cluster guidance for PCI DSS 4.0.1 demonstrates deploying in-scope and out-of-scope pods to separate node pools using taints, so the two sets never share a node VM.

That implementation detail carries a matrix implication most teams miss. Node-pool isolation is a platform-team execution task, but the scoping decision behind it, which workloads are in the cardholder data environment, is a compliance-team responsibility that cannot be delegated to whoever runs the nodes. For regulated clusters, your matrix has to split rows that a general-purpose matrix leaves merged, because the framework requires separation of duties that informal ownership blurs.

Get your Kubernetes responsibility matrix right

You now have the boundaries. The harder part is operating the shared columns between what the provider owns and what your teams keep. This includes node operations and add-on lifecycle, as well as observability and incident response. That is where a matrix on paper meets the reality of who picks up the pager.

ABS Technologies is an Armenia-based Managed IT Services Provider whose practices map onto the working columns of this matrix. Its Managed IT Services and DevOps work covers the operator column. Its Cloud Services work supports the platform column, and its Information Security practice supports the security column where policy intent and evidence live. Because ABS is vendor-independent, it can advise across managed Kubernetes services and self-managed clusters without steering you toward a single brand.

The useful next step is a working session to define which rows of your matrix ABS takes on and which stay in-house, with evidence and an escalation path attached to each shared row so the result survives an audit. Bring your current RACI, or the gaps where one should be, and start from there.