Kubernetes + Vault for tenant isolation
Direct answer
Canonical Kubernetes gives you a cluster. HashiCorp Vault gives workloads a controlled way to obtain secrets. A tenant platform still has to connect those systems to customer identity, release boundaries, policy, domains, upgrades, rotation, and deletion. OpenTenant automates that missing lifecycle: one tenant declaration is reconciled into an isolated release, a scoped Vault path, tenant configuration, and routing.
This guide separates the upstream setup from the orchestration OpenTenant adds. The commands below are useful starting points, not a production security baseline.
Start with a Kubernetes cluster
Canonical documents a compact installation path for its upstream Kubernetes distribution using the
k8s snap:
sudo snap install k8s --classic
sudo k8s bootstrap
sudo k8s status
sudo k8s kubectl get all --all-namespaces
According to Canonical's installation guide, the distribution includes networking, gateway, local storage, DNS, a load balancer, metrics server, and ingress. A multi-node cluster is formed with a join token, and Canonical states that three or more control-plane nodes automatically provide high availability.
That gets a cluster running. It does not decide which customer owns which workloads, secrets, hostnames, or release history.
Connect Kubernetes to an external Vault
HashiCorp's external Vault tutorial demonstrates a Kubernetes workload retrieving secrets from a Vault service outside the cluster. Its lab uses minikube, a Vault dev server, the Kubernetes authentication method, a policy and role, and Vault Agent Injector.
The important production pattern is the trust path:
- A Kubernetes service account identifies the workload.
- Vault's Kubernetes auth method validates that identity.
- A Vault role binds approved service accounts and namespaces to a policy.
- The policy grants only the required secret paths and capabilities.
- An injector or operator delivers secret material to the workload.
HashiCorp explicitly warns that its dev server and root-token workflow are insecure and should not be used in production. A production deployment also needs TLS, a durable and highly available Vault service, controlled network reachability, auditable policies, and a rotation model.
Choose how secrets reach workloads
There is no single delivery pattern for every application.
Vault Agent Injector adds a sidecar or init workflow that authenticates to Vault and renders secrets into the pod filesystem. This can avoid putting application credentials directly into environment variables.
Vault Secrets Operator or External Secrets Operator reconciles external values into Kubernetes resources. This works well for charts that already expect Kubernetes Secrets, but it means Kubernetes becomes part of the delivery path and must be protected accordingly.
OpenTenant's current architecture uses a Vault-backed tenant registry with operator-driven materialization. The tenant record is the contract: identity, enabled state, secret references, release configuration, and routing inputs can be reconciled without placing long-lived secrets in the OpenTenant application service.
Why the quickstart is not a tenant platform
A working cluster plus a working Vault login still leaves the most consequential questions unanswered:
- Does each tenant receive a namespace, a release, or an entire cluster?
- Which service accounts can authenticate to which Vault roles?
- Can one tenant reference another tenant's secret path?
- What happens when a credential rotates?
- Which pods restart, and how is blast radius contained?
- Who owns ingress, TLS, DNS, backups, upgrades, and offboarding?
- What evidence connects a Git change to the running tenant release?
Namespace boundaries are useful, but they are not a complete hard-security boundary on their own. Production isolation should also include RBAC, NetworkPolicy, admission controls, workload security settings, resource quotas, and carefully scoped cloud identities.
How OpenTenant compiles the tenant lifecycle
OpenTenant does not replace Kubernetes or Vault. It turns their primitives into repeatable tenant operations.
tenant declaration
→ validate template and allowed configuration
→ resolve tenant identity and Vault scope
→ create or reconcile namespace
→ bind service account, Vault role, and secret references
→ install or upgrade one Helm release
→ configure tenant domain and route
→ observe readiness and retain rollback provenance
The unit of operation is the tenant, not an ad hoc sequence of shell commands. For each tenant, OpenTenant can keep the same base chart while applying approved values such as replicas, feature flags, branding, and domain configuration. Credentials remain referenced through the tenant's Vault scope.
When a secret changes, the operator layer updates the intended Kubernetes delivery mechanism. A reloader can then restart only the workloads that depend on the changed Secret. The desired outcome is a contained rollout for one tenant—not a platform-wide restart.
Security boundaries that remain explicit
Automation is valuable only when the policy is visible. A production OpenTenant profile should make these controls reviewable:
Vault path policy
Use a tenant-derived path that cannot be selected freely by untrusted input. Bind it to narrowly scoped Vault policies and Kubernetes service accounts. Avoid wildcard permissions that span the tenant registry.
Kubernetes identity
Create service accounts per tenant or per workload class. Restrict role bindings to the intended namespace and avoid default service-account credentials when they are not needed.
Network isolation
Start from deny-by-default NetworkPolicies and add only the egress and ingress required by the chart, Vault delivery pattern, observability stack, and edge connector.
Release provenance
Record the chart reference, version, values hash, source revision, and reconciliation result. A tenant upgrade should be explainable and reversible.
Safe deletion
Offboarding should disable access first, then remove routing, release resources, and secret references according to a retention policy. Destruction should not be an unreviewed side effect of a missing record.
Evaluation checklist
Before calling the system production-ready, verify:
- Kubernetes control-plane and node availability match the environment's recovery objectives.
- Vault is not running in dev mode and root tokens are not used for routine operations.
- Kubernetes authentication validates the intended issuer, API endpoint, and service accounts.
- Vault policies cannot traverse into another tenant's path.
- Secret delivery and rotation are tested for the actual Helm chart.
- RBAC and NetworkPolicy prevent cross-tenant access in negative tests.
- Tenant creation and upgrade are idempotent.
- Failed reconciliation does not leave public routes or credentials orphaned.
- Backup, restore, audit logging, and deletion behavior are documented.
Sources
OpenTenant's role begins where those installation guides end: turning proven infrastructure components into a consistent, tenant-scoped operating model.