11. Kubernetes Security and Zero-Trust Architecture

Introduction and Context

Kubernetes has become a foundational platform for deploying distributed applications, but its flexibility also creates a large security responsibility. A cluster is not merely a collection of containers. It is a control system that authenticates users and machines, schedules workloads, stores sensitive information, connects services, exposes APIs, and interacts with external cloud resources. A weakness in any of these relationships can affect the confidentiality, integrity, or availability of an entire application estate.

Kubernetes security must therefore be understood as an architectural discipline rather than as the installation of a single security product. It combines identity management, authorization, workload isolation, supply-chain assurance, secrets protection, network controls, admission policies, runtime monitoring, encryption, governance, and incident response. These controls are most effective when they reinforce one another through defense in depth.

Zero-trust architecture provides an appropriate strategic model for this discipline. It rejects the assumption that a request is trustworthy merely because it originates inside a cluster or corporate network. Each request should be authenticated, authorized according to context, limited in scope, monitored, and periodically re-evaluated. Kubernetes does not automatically implement zero trust, but its declarative APIs and extensible control plane provide mechanisms through which zero-trust principles can be applied.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the security architecture of a Kubernetes cluster and identify its principal trust boundaries.

2. Apply authentication, RBAC, workload identity, and least-privilege principles.

3. Design approaches for secrets management and encryption of sensitive data.

4. Use admission control, network policies, runtime protection, and tenant isolation to reduce risk.

5. Conduct a threat-modeling exercise for a Kubernetes-based application.

6. Relate Kubernetes controls to zero-trust and defense-in-depth frameworks.

7. Evaluate practical trade-offs involving usability, performance, governance, and operational complexity.

Kubernetes as a Set of Trust Relationships

A Kubernetes deployment contains several security domains. The control plane includes the API server, scheduler, controller managers, and persistent storage such as etcd. Worker nodes host the kubelet, container runtime, and application workloads. Administrators, developers, CI/CD systems, cloud providers, registries, identity providers, and observability platforms interact with the cluster from outside these components.

The Kubernetes API server is the central security boundary. Most administrative actions pass through it, and it performs authentication, authorization, admission processing, and object validation before persisting accepted state. Protecting the API server requires more than restricting its network endpoint. Its credentials, audit trail, admission configuration, and connection to etcd must also be protected.

The kubelet is another important boundary. It receives instructions concerning pods scheduled to its node and interacts with the container runtime. A compromised kubelet or node may expose workload data, service-account tokens, mounted secrets, and network traffic. Consequently, node hardening and workload isolation remain necessary even when the API server is strongly protected.

The security objective is not simply to prevent unauthorized access to the cluster. It is to limit the consequences of inevitable mistakes and compromises. A developer account should not be able to read production secrets; a compromised pod should not automatically reach every service; and a workload identity should not possess broad permissions across an entire cloud account.

Core Concepts and Terminology

Authentication establishes who or what is making a request. Kubernetes may use client certificates, bearer tokens, service-account tokens, external identity providers, or authentication proxies. Authorization determines whether an authenticated principal may perform a specific action on a resource. Admission control evaluates and potentially modifies or rejects a request after authentication and authorization.

A principal can be a human user, group, service account, workload identity, CI/CD system, or external automation process. A resource is an API object such as a pod, deployment, secret, role, or custom resource. An action is commonly represented by a verb such as get, list, watch, create, update, patch, delete, or impersonate.

RBAC, or role-based access control, expresses authorization through roles and bindings. A Role applies within a namespace, whereas a ClusterRole may apply across a cluster or be bound within a namespace. A RoleBinding assigns permissions to subjects within a namespace; a ClusterRoleBinding grants cluster-wide authority. The distinction is operationally significant: a narrowly scoped ClusterRole can be useful, but a broad ClusterRoleBinding can become a major escalation path.

A namespace is a logical grouping mechanism, not a complete security boundary. Namespaces support resource quotas, policy attachment, and administrative separation, but cluster administrators, privileged workloads, host-mounted paths, and certain network configurations can cross namespace boundaries. Strong tenant isolation may require separate node pools, clusters, cloud accounts, or even separate control planes.

A secret is Kubernetes data intended for sensitive values such as passwords, keys, or tokens. The existence of a Secret object does not automatically mean that the value is safely protected. Access permissions, encryption at rest, API exposure, audit records, volume mounts, environment variables, backups, and external integrations all influence its security.

Identity, RBAC, and Workload Identity

Human identity should normally be federated through an enterprise identity provider rather than represented by long-lived, individually managed credentials inside Kubernetes. Federation supports centralized authentication, multi-factor authentication, employee lifecycle management, group membership, and conditional access. The Kubernetes API server can trust identity assertions from an external provider, while authorization remains governed by Kubernetes RBAC.

A sound RBAC design begins with roles rather than individuals. Permissions should be grouped according to job function or workload responsibility, then assigned through groups or service accounts. The principle of least privilege requires limiting not only the resources that a principal may access but also the verbs, namespaces, resource names, and time during which access is valid.

For example, a deployment pipeline may need to update Deployments in a release namespace but have no reason to read Secrets, create Nodes, or modify admission policies. A monitoring agent may need to watch selected metrics-related resources but should not receive unrestricted access to pod contents. The permissions to list or watch resources deserve particular care because metadata may reveal service names, image references, environment details, or secret-related information.

Service accounts provide identities for workloads. Pods can receive service-account tokens, but automatic token mounting should be disabled when a workload does not need to call the Kubernetes API. Short-lived, projected tokens are preferable to legacy long-lived tokens because they reduce the value of stolen credentials. Token audiences should be constrained so that a token intended for one service cannot be reused indiscriminately with another.

Workload identity extends this idea to cloud services. Instead of placing a cloud access key in a container, a workload is associated with a cloud identity through mechanisms provided by the platform, such as federated service-account credentials. The cloud provider then issues temporary credentials according to an identity policy. This approach reduces static secrets, but it does not eliminate authorization risk. A compromised pod can still misuse the permissions granted to its identity. Cloud permissions must therefore be narrowly scoped, and identity associations must be audited.

Impersonation permissions require special protection. A principal able to impersonate a more privileged user or service account may effectively bypass the intended RBAC design. Similarly, permissions to create pods in a namespace can be dangerous if the namespace allows access to powerful service accounts, host paths, or sensitive secrets.

Secrets Management and Encryption

Secrets should be treated as a lifecycle rather than as static strings. The lifecycle includes creation, distribution, use, rotation, revocation, backup, recovery, and destruction. Kubernetes Secrets are encoded for transport representation, but encoding is not equivalent to encryption. Encryption at rest should be enabled for sensitive resources in etcd, preferably using a carefully protected external key-management service or a robust key-encryption-key hierarchy.

External secret managers can provide stronger lifecycle management. A controller or CSI-based integration can retrieve values from a cloud or enterprise vault and make them available to workloads without requiring developers to store plaintext credentials in source repositories. The integration itself must be secured: its identity, access policy, synchronization behavior, cache, and failure mode all require review.

Environment variables are convenient but may be exposed through debugging output, process inspection, crash reports, or accidental logging. Mounted files may provide better control in some cases, but they also require correct filesystem permissions and protection against unintended volume access. Applications should retrieve only the secrets they need and should avoid logging them.

Rotation is effective only when applications can tolerate it. A mature design supports overlapping credentials, dynamic retrieval, connection refresh, and revocation. Backups and snapshots must be included in the analysis because encrypting a live cluster does not protect an unencrypted backup containing the same secrets.

Admission Control and Policy as Code

Authentication and RBAC decide whether a request is associated with an authorized principal. Admission control provides an additional opportunity to evaluate the object being submitted. Admission webhooks and policy engines can reject workloads that violate organizational requirements, while validating and mutating policies can standardize safe defaults.

Useful admission policies may require non-root execution, disallow privileged containers, prohibit host networking and host PID access, require approved registries, enforce resource requests and limits, require labels for ownership, restrict dangerous capabilities, and ensure that images are signed or have passed vulnerability checks. Policies should distinguish between genuine exceptions and ordinary convenience. An unrestricted emergency bypass gradually becomes the normal operating model.

Policy as code makes security rules version-controlled, reviewable, testable, and auditable. However, a policy can be technically correct but operationally harmful if it blocks legitimate recovery or produces ambiguous messages. Policies should be introduced in stages: observe violations, communicate the expected standard, remediate workloads, and then enforce. Break-glass procedures should be narrowly controlled, time-limited, logged, and reviewed afterward.

Image security is closely related to admission. Scanning identifies known vulnerabilities, but a scan is not a complete trust decision. Organizations should also consider image provenance, build reproducibility, base-image maintenance, software bills of materials, signature verification, and whether the image runs with unnecessary privileges. Admission can connect these supply-chain signals to deployment decisions.

Network Segmentation and Service-to-Service Trust

A Kubernetes network commonly permits broad pod-to-pod communication unless NetworkPolicy rules restrict it. This default can make initial development easy but creates excessive lateral movement after compromise. Network policies should express an allow-list model: a workload is permitted to receive traffic only from known sources and on required ports, while egress is limited to approved destinations where practical.

Policies should be designed around application flows rather than namespace names alone. A web frontend may accept traffic from an ingress gateway and call an API service; the API may call a database and an identity provider; neither should automatically communicate with unrelated workloads. Egress controls are especially valuable for reducing command-and-control traffic and unauthorized data exfiltration.

NetworkPolicy support varies by network plugin, and policies may not protect all node-level or external paths. Teams must understand whether their implementation supports ingress, egress, named ports, host traffic, and logging. Service meshes can add mutual TLS, service identity, traffic authorization, and telemetry, but they introduce sidecars or ambient components, certificate-management dependencies, and operational complexity. A service mesh is not a substitute for RBAC, secure application logic, or node hardening.

Zero-trust service communication requires more than encryption. Mutual TLS proves that a connection is associated with a service identity, while an authorization policy determines whether that identity is allowed to perform the requested operation. Application-level authorization remains necessary because a valid service identity does not imply permission to access every function.

Runtime Protection and Node Security

Preventive controls cannot eliminate all attacks. Runtime protection detects or blocks suspicious behavior such as unexpected process execution, access to sensitive host paths, privilege escalation, unusual system calls, crypto-mining activity, or anomalous network connections. Detection rules should be connected to a response process; alerts without ownership and triage become background noise.

Containers should run as non-root users where possible, use a read-only root filesystem when feasible, drop unnecessary Linux capabilities, apply seccomp and other mandatory access controls, and avoid privileged mode. Resource requests and limits reduce some forms of denial-of-service risk, although they must be sized carefully to avoid instability.

Nodes require secure operating-system baselines, timely patching, restricted administrative access, protected kubelet endpoints, disk encryption where appropriate, and controlled use of host mounts. Container runtimes, node agents, and kernel components should be included in vulnerability management. A pod that mounts the host filesystem or accesses the container runtime socket may be able to escape intended isolation; such configurations should be exceptional and closely reviewed.

Runtime telemetry should be correlated with API audit logs, cloud activity logs, image information, and network observations. Forensic readiness matters: time synchronization, retention policies, immutable storage, and a documented response procedure can determine whether an incident is understood or remains speculative.

Tenant Isolation and Multi-Cluster Decisions

Multi-tenancy may refer to several different situations: teams sharing a cluster, environments sharing a cluster, customers sharing infrastructure, or unrelated organizations using a managed platform. The required isolation strength differs substantially among these cases.

Namespace-based tenancy is economical and often suitable for teams with a common administrative authority. It should be combined with RBAC, quotas, default-deny network policies, admission controls, and restricted workload profiles. Separate node pools may reduce interference and support different compliance requirements, but they do not by themselves create a complete security boundary.

A dedicated cluster provides stronger administrative and failure-domain separation, at the cost of additional control-plane operations, upgrades, monitoring, and governance. Separate cloud accounts or subscriptions can further isolate billing, identities, keys, and network resources. The decision should consider threat actors, regulatory obligations, blast radius, availability requirements, operational maturity, and cost rather than relying on a universal rule.

Threat Modeling a Kubernetes Application

Threat modeling makes security reasoning explicit before an incident occurs. A practical method is to map assets, actors, trust boundaries, attack paths, controls, and residual risks. Assets may include source code, customer data, credentials, signing keys, cluster state, and availability. Actors may include malicious users, compromised developers, hostile tenants, external attackers, malicious insiders, and compromised dependencies.

A data-flow diagram should show traffic among users, ingress components, services, databases, the API server, registries, identity providers, and cloud services. Each boundary should prompt questions: what authenticates the request, what authorizes it, what data crosses the boundary, and what evidence is recorded?

Threat categories can include spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. In Kubernetes, examples include stolen service-account tokens, a poisoned image, excessive RBAC, admission bypass, vulnerable ingress components, exposed dashboards, compromised nodes, and secrets appearing in logs.

Risk treatment should prioritize controls that reduce both likelihood and blast radius. A useful sequence is to remove unnecessary access, constrain identities, segment communication, enforce secure workload profiles, protect secrets, monitor meaningful events, and rehearse recovery. Residual risk should be accepted by an accountable owner rather than silently inherited by the platform team.

An Illustrative Case: Protecting a Multi-Team Financial Platform

Background

A fictional financial-services organization operates customer-facing APIs, internal analytics, and batch processing workloads on a managed Kubernetes service. Development, testing, and production teams share a cluster to reduce operating cost. The organization uses an external identity provider and a cloud key-management service.

Situation and Analysis

An internal review finds that developers can deploy arbitrary pods in a shared namespace and that service-account tokens are automatically mounted. Several workloads use a shared cloud credential stored as a Kubernetes Secret. Network policies are absent, production images are pulled from multiple registries, and audit logs are retained only briefly. A compromised development pod could potentially read local service tokens, communicate with production services, and use the shared cloud credential to access storage.

The threat model identifies elevation of privilege, lateral movement, credential theft, supply-chain compromise, and insufficient forensic evidence as the principal risks. The most serious weakness is not one individual misconfiguration but the combination of broad identity, weak segmentation, and shared credentials.

Approach and Strategy

The platform team first separates production and non-production namespaces and maps each deployment pipeline to a dedicated service account. RBAC is rewritten around narrowly scoped roles; pipelines may update approved workload resources but cannot read Secrets or modify cluster-wide objects. Automatic token mounting is disabled unless required, and projected short-lived tokens are used for necessary API access.

The shared cloud credential is removed. Workloads receive separate cloud identities with permissions limited to particular services and resources. Secrets are stored in an external vault, encrypted through the organization’s key-management service, and retrieved only by approved workloads. Network policies implement default-deny behavior and explicitly permit ingress, API-to-database, and required external flows.

Admission policies require signed images from approved registries, non-root execution, restricted capabilities, resource limits, and required ownership labels. Runtime monitoring watches for unexpected shell execution, privileged behavior, and access to sensitive paths. API audit logs and cloud logs are sent to protected centralized storage. A controlled break-glass role is created for emergencies and reviewed after every use.

Outcome

The redesign does not claim to make compromise impossible. Instead, it reduces the number of viable attack paths and limits the blast radius of a compromised workload. Developers retain sufficient autonomy within their namespaces, while production access requires stronger identity and approval controls. Security testing becomes part of the deployment process, and the organization can investigate suspicious activity with more reliable evidence.

Learning Points

The case illustrates that zero trust is implemented through accumulated decisions: explicit identity, narrow authorization, segmented communication, protected secrets, verified software, observable operations, and accountable exceptions. It also shows why a security program should address relationships among controls rather than treating each configuration item independently.

Governance, Ethics, and Operational Responsibility

Security controls affect people as well as systems. Excessive monitoring can expose employee activity or customer data, while poorly designed access restrictions may prevent legitimate operational work. Organizations should define purpose, retention, access, and oversight for security telemetry. Audit data should be protected from unauthorized alteration and handled according to privacy and regulatory obligations.

Governance should assign responsibility for cluster administration, workload ownership, policy exceptions, key management, vulnerability remediation, incident response, and evidence retention. Compliance frameworks may require encryption, access reviews, separation of duties, change records, or breach reporting, but compliance should not replace engineering judgment. A control is valuable when it reduces a meaningful risk and can operate reliably.

Security teams should avoid treating developers as the enemy. Secure platform abstractions, reusable templates, policy feedback, self-service identity integration, and clear escalation paths make the secure path easier to follow. Ethical practice includes minimizing unnecessary data collection, communicating monitoring transparently, and ensuring that emergency access is not used for routine convenience.

Common Failure Modes and Best Practices

Frequent mistakes include granting cluster-admin for convenience, using one service account across applications, storing cloud keys in images or repositories, assuming base64 is encryption, allowing unrestricted egress, trusting namespace boundaries as complete isolation, ignoring image provenance, and deploying admission policies without a recovery plan.

A mature Kubernetes security program generally follows these practices:

• Establish centralized, federated human identity with strong authentication.
• Use least-privilege RBAC and review permissions regularly.
• Disable unnecessary token mounting and prefer short-lived workload credentials.
• Encrypt sensitive data at rest and protect encryption keys separately.
• Use external secret management and implement tested rotation.
• Enforce secure workload profiles through admission policy.
• Apply default-deny network segmentation where operationally feasible.
• Harden nodes, runtimes, kubelets, and administrative interfaces.
• Verify image provenance and integrate supply-chain checks into deployment.
• Correlate audit, runtime, network, registry, and cloud events.
• Test backup recovery, incident response, and break-glass procedures.
• Reassess isolation architecture as tenant risk and regulatory requirements change.

Current Developments and Emerging Directions

Kubernetes security is increasingly influenced by workload identity federation, software supply-chain frameworks, signed artifacts, software bills of materials, confidential-computing options, and policy engines integrated into continuous delivery. Platform teams are also adopting identity-aware proxies, adaptive authorization, and automated drift detection.

Artificial intelligence can assist with anomaly detection, policy analysis, alert correlation, and identification of unusual privilege use. Its outputs should remain advisory or subject to human-controlled safeguards in high-impact decisions. Automated remediation can itself cause outages if it revokes credentials or isolates services without adequate context.

The direction of travel is toward continuously evaluated security: identities, software artifacts, workload posture, communication context, and behavioral evidence are assessed throughout the application lifecycle. This reinforces the central lesson of zero trust: trust is not a permanent property of a network location or a past authentication event.

Chapter Summary

Kubernetes security is a layered discipline involving identity, authorization, admission, secrets, encryption, network segmentation, runtime protection, node security, supply-chain assurance, and governance. RBAC should follow least privilege, while workload identity should replace static cloud credentials wherever practical. Secrets require lifecycle management, encryption at rest, controlled distribution, and tested rotation.

Admission policies can enforce secure workload standards and connect deployment decisions to image provenance and vulnerability information. Network policies and service identity reduce lateral movement, but namespaces alone are not complete tenant boundaries. Runtime monitoring, audit evidence, and incident response limit the impact of controls that fail or attacks that succeed.

Zero-trust architecture provides the organizing principle: authenticate explicitly, authorize narrowly, verify continuously, segment communication, minimize blast radius, and record meaningful evidence. Threat modeling helps organizations select controls according to assets, actors, trust boundaries, and attack paths. Effective security is therefore both technical and organizational, requiring governance, accountability, usability, and continuous reassessment.

Key Terms

Authentication: The process of verifying the identity of a user, workload, or system.

Authorization: The decision about which actions an authenticated principal may perform.

RBAC: Role-based access control that assigns permissions through roles and bindings.

Role: A collection of permitted API actions, scoped to a namespace or cluster.

Service Account: A Kubernetes identity intended for use by workloads or automation.

Workload Identity: A mechanism that associates a workload with a temporary external or cloud identity.

Admission Control: Processing that validates or modifies API requests before they are accepted.

Secret: An object or value containing sensitive information such as a key or password.

Encryption at Rest: Protection of stored data so that it cannot be read without the required key.

Network Policy: A rule defining permitted network communication for selected workloads.

Zero Trust: A security model requiring explicit verification and authorization rather than implicit network trust.

Defense in Depth: The use of multiple reinforcing controls so that one failure does not expose the entire system.

Tenant Isolation: Separation of workloads, identities, data, and administration belonging to different users or groups.

Threat Modeling: Structured analysis of assets, actors, attack paths, controls, and risks.

Runtime Protection: Detection or prevention of suspicious behavior while workloads are executing.

Image Provenance: Evidence concerning the origin, build process, and integrity of a container image.

Break-Glass Access: Exceptional emergency access that is restricted, logged, and reviewed.

Blast Radius: The extent of damage or access possible after a component is compromised.

Review Questions

Short Answer Questions

1. Why is a Kubernetes namespace not, by itself, a complete security boundary?

2. Distinguish authentication, authorization, and admission control.

3. Why are short-lived projected service-account tokens preferable to long-lived credentials?

4. What security problem does a default-deny NetworkPolicy help address?

5. State two reasons why base64 encoding does not protect a Kubernetes Secret.

Long Answer Questions

1. Explain how RBAC and workload identity can be designed according to least-privilege principles.

2. Discuss the lifecycle requirements for secure secrets management in Kubernetes.

3. Explain how admission control contributes to defense in depth and software supply-chain security.

4. Compare namespace-based tenancy, separate node pools, and separate clusters as isolation strategies.

5. Describe a comprehensive runtime and node-security strategy for a production Kubernetes environment.

Analytical / Application Questions

1. A CI/CD account can create pods, read Secrets, and modify ClusterRoles. Analyze the likely attack paths and propose a revised permission model.

2. Design a threat model for a web frontend, API service, and database running in Kubernetes. Identify trust boundaries, major threats, and controls.

3. An organization wants to host unrelated external customers in one cluster to reduce cost. Evaluate the security and governance factors that should determine whether this architecture is acceptable.

22. Multiple Choice Questions with Answers

Question 1

A deployment pipeline only needs to update Deployments in one namespace. Which RBAC design best follows least privilege?

A. Grant cluster-admin to the pipeline service account

B. Grant a namespace-scoped Role allowing required Deployment actions and bind it in that namespace

C. Grant a ClusterRoleBinding allowing all verbs on all resources

D. Use the node identity for all pipeline operations

Correct Answer: B. Grant a namespace-scoped Role allowing required Deployment actions and bind it in that namespace

Question 2

What is the principal security weakness of treating base64-encoded Kubernetes Secret data as protected?

A. Base64 prevents Kubernetes from mounting the data

B. Base64 provides representation, not confidentiality or encryption

C. Base64 makes rotation impossible

D. Base64 automatically exposes data to every namespace

Correct Answer: B. Base64 provides representation, not confidentiality or encryption

Question 3

Which control most directly reduces lateral movement between compromised pods?

A. Increasing pod CPU limits

B. Using descriptive deployment names

C. Applying default-deny NetworkPolicies with explicit allowed flows

D. Adding more container replicas

Correct Answer: C. Applying default-deny NetworkPolicies with explicit allowed flows

Question 4

A pod does not call the Kubernetes API. Which action reduces unnecessary credential exposure?

A. Enable automatic service-account token mounting

B. Disable automatic service-account token mounting

C. Grant the pod cluster-admin permissions

D. Store a permanent administrator token in an environment variable

Correct Answer: B. Disable automatic service-account token mounting

Question 5

Why can a permission to create pods be dangerous in a namespace?

A. It always deletes existing pods

B. It may allow a user to create a pod that accesses powerful identities, host paths, or secrets

C. It prevents admission policies from running

D. It automatically grants access to the cloud billing system

Correct Answer: B. It may allow a user to create a pod that accesses powerful identities, host paths, or secrets

Question 6

Which statement best expresses a zero-trust approach to service communication?

A. All traffic inside the cluster is trusted

B. Authentication is needed only at the external ingress

C. Service identity and authorization are evaluated for each relevant communication path

D. Encryption alone guarantees authorization

Correct Answer: C. Service identity and authorization are evaluated for each relevant communication path

Question 7

Which admission policy most directly addresses workload privilege escalation?

A. Require application labels only

B. Require non-root execution and prohibit privileged containers

C. Permit all images from every registry

D. Remove resource limits

Correct Answer: B. Require non-root execution and prohibit privileged containers

Question 8

A workload uses a shared cloud access key stored in a Kubernetes Secret. Which redesign is strongest?

A. Copy the key into every container image

B. Place the key in a second namespace

C. Use a narrowly scoped federated workload identity with temporary credentials

D. Give every workload the same administrator key

Correct Answer: C. Use a narrowly scoped federated workload identity with temporary credentials

Question 9

What is the primary purpose of threat modeling in Kubernetes security?

A. To guarantee that no vulnerability can occur

B. To map assets, actors, boundaries, attack paths, and controls so risks can be prioritized

C. To replace monitoring and incident response

D. To eliminate the need for access reviews

Correct Answer: B. To map assets, actors, boundaries, attack paths, and controls so risks can be prioritized

Question 10

Which option provides the strongest isolation for unrelated high-risk tenants, assuming additional cost is acceptable?

A. A shared namespace with no policies

B. Separate labels in one namespace

C. A shared cluster with unrestricted cluster-admin access

D. Separate clusters, potentially combined with separate cloud accounts

Correct Answer: D. Separate clusters, potentially combined with separate cloud accounts