Shared platform vs dedicated clusters: control plane isolation and policy-as-code

Security conversations often collapse into a binary: shared is insecure, dedicated is secure. Reality is more nuanced. Shared hosting can be appropriately isolated for most production workloads, we enforce that with Calico, admission control, and generated NetworkPolicies. Dedicated clusters exist for teams whose threat model, compliance obligations, or operational requirements need stronger separation than a namespace boundary provides.

This article explains what changes when you move from shared platform hosting to a dedicated cluster: control plane isolation, infrastructure boundaries, and how policy-as-code works in each model.

Two models, one policy language

StackBlaze uses the same declarative primitives in both models, Kubernetes RBAC, NetworkPolicy, Pod Security Standards, and GitOps-friendly resource definitions. What changes is who owns the enforcement boundary, where the control plane runs, and how much latitude you have to customize policies without platform guardrails.

Shared platform: policy-as-code with guardrails

On shared hosting, you declare intent in the dashboard, which services exist, what they connect to, whether traffic is public or internal, and the platform materializes the correct RBAC, secrets wiring, Calico network policies, and Linkerd identities. You do not manage the CNI, mesh, or runtime detection stack yourself. That is intentional: a single misconfigured allow-all rule on a shared cluster could affect hundreds of tenants.

Policy-as-code on the shared platform works in three layers: the intent you express when wiring services together, the platform policy model that validates those connections for safety, and continuous reconciliation that keeps the live cluster aligned with that model. Drift, a manual change that bypasses the model, is detected and reverted within minutes.

Dedicated clusters: isolated control plane and infrastructure

A dedicated cluster is a separately provisioned Kubernetes cluster whose control plane (API server, scheduler, controller manager, etcd) serves only your organization. Worker nodes are not shared with other customers. Calico runs with the same core capabilities, but you, or our managed GitOps pipeline on your behalf, own the full policy surface.

What "isolated control plane" means operationally

• Separate etcd with encryption at rest using keys scoped to your cluster
• Dedicated API server endpoint, not shared with other tenants' kubectl traffic
• Platform operators access via break-glass audited sessions, not standing admin on your data plane
• Upgrade windows negotiated per cluster; you can pin Kubernetes minor versions during change freezes
• Audit logs export to your SIEM without co-mingling other customers' events

Infrastructure isolation goes further: nodes run in your dedicated pool, persistent volumes are provisioned from storage backends with per-cluster encryption boundaries, and cross-cluster networking uses private links rather than shared ingress controllers where required.

Policy ownership on dedicated clusters

Dedicated customers who need finer control can extend the baseline with custom network rules, admission constraints (via Gatekeeper or Kyverno), and additional Falco detections, all managed through GitOps workflows the platform supports but does not impose. StackBlaze provides starter templates that mirror the shared platform baselines so you start restrictive and open only what you need.

A common dedicated-cluster pattern is layering Linkerd authorization policies on top of Calico: Calico enforces which namespaces and ports may communicate; Linkerd enforces which service identity is allowed to call a specific route. Falco adds a third layer for behaviors neither network nor mesh controls can see, a reverse shell, a cryptominer process spawn, an unexpected mount of the service account token.

On shared hosting, platform-wide rules like blocking access to cloud instance metadata endpoints are applied uniformly. On dedicated clusters, you decide how strict those egress boundaries are, globally, per namespace, or with exceptions for specific exporters, in exchange for owning the review and audit trail.

Policy review in practice

Dedicated cluster onboarding includes a policy review workflow: every change to network, mesh, or runtime rules goes through peer review before it reaches production. We flag common mistakes, overly broad ingress, missing default deny, containers running as root without justification, secrets stored in plain configuration, so your team catches them before an auditor does.

When to stay on shared hosting

Shared hosting is not a "lesser" tier. For most teams it is the correct security and cost trade-off:

• You need strong tenant isolation but not a dedicated control plane
• Your compliance requirements are met by SOC 2 Type II on the platform plus your own application controls
• You want NetworkPolicy enforcement without hiring a platform team to maintain Calico
• Your environments are dev/staging/production for a single product, not dozens of independently governed business units

When dedicated clusters are worth it

• Contractual requirement for single-tenant infrastructure (common in finance, healthcare, and government)
• Need to run custom admission webhooks, operators, or CNI-adjacent tooling the shared platform cannot host
• Data residency rules requiring compute and storage in a specific account boundary you audit directly
• Kubernetes version pinning during long validation cycles for validated systems (GxP, PCI segmented environments)
• Requirement to hold your own encryption keys for etcd and persistent volumes (BYOK)

Migration path

Teams often start on shared hosting and migrate specific production environments to dedicated clusters when compliance milestones approach, Series B due diligence, enterprise customer security reviews, or HIPAA readiness. Because the workload definitions are the same, migration is primarily a data copy and DNS cutover, not a rewrite.

We export the effective policy graph from your shared environment and translate it into a GitOps starter repository for your dedicated cluster, so you do not lose the isolation properties you already had, you inherit them as explicit, reviewable policy definitions.

Choosing with your auditor in the room

Auditors rarely ask "shared or dedicated?" in abstract terms. They ask: Who can access production data? How is lateral movement prevented? Where are logs retained? Can you show policy enforcement evidence? Shared hosting answers those questions with platform-managed Calico, Linkerd, and Falco telemetry plus centralized audit trails. Dedicated clusters add single-tenant infrastructure evidence, useful when the question is "prove no other customer shares this control plane."

Our third article in this series covers regulatory frameworks, data governance, and how to map StackBlaze controls to SOC 2, GDPR, and HIPAA-oriented questionnaires, regardless of which hosting model you choose.