Projects and multi-tenancy

Overview

One of the key challenges in implementing fleet management throughout an enterprise is balancing two competing concerns: gaining single-pane-of-glass management over your Kubernetes estate across multiple organizations or lines of business, and adhering to the principle of least privilege and other security best practices that are easily tossed by the wayside when implementing that degree of automation. In particular, these main concerns need to be satisfied to confidently implement fleet management:

1. Owners of a subset of resources cannot edit resources outside their domain.
2. There is no single store of credentials for the entire fleet (if one cluster is compromised, that doesn't imply the entire enterprise is compromised).
3. It is still seamless to create, destroy, and update any cluster within the fleet and maintain line-of-sight into what's running within them.

Plural allows you to address all three of these core concerns using several clever constructs, namely Projects (for segmenting resources within Plural under specific sets of bound policies), NamespaceCredentials (for overriding the credentials our operator uses to reconcile resources with specific configured ones, making sure GitOps doesn't become implicit God-mode), and ServiceAccount (which allows you to quickly provision assumable bot accounts, like Kubernetes service accounts, which can then be fed into Terraform Stacks or NamespaceCredentials to seamlessly bound permissions throughout the system).

TLDR

If you'd rather see a live demo, watch the video below, which goes over this in full detail in the context of a working example:

Setup

The core of how tenancy is managed at scale is via Projects. An example of how this can be set up is below:

apiVersion: v1
kind: Namespace
metadata:
  name: gke-fleet # this will be the namespace all Plural CRDS for `gke-fleet` live in for your management cluster
---
apiVersion: deployments.plural.sh/v1alpha1
kind: ServiceAccount
metadata:
  name: gke-fleet
spec:
  email: gke-fleet-fleet@plural.sh # the Plural service account user that will be admin for that Project
  tokenSecretRef:
    name: gke-fleet-sa-token # a secret that its access token will be dumped to
    namespace: gke-fleet
---
apiVersion: deployments.plural.sh/v1alpha1
kind: Project
metadata:
  name: gke-fleet
spec:
  name: gke-fleet
  description: resources for managing the gke-fleet fleet
  bindings:
    write:
    - userEmail: gke-fleet-fleet@plural.sh # adds the user as a writer for the project (by email)
---
apiVersion: deployments.plural.sh/v1alpha1
kind: NamespaceCredentials
metadata:
  name: gke-fleet
spec:
  namespaces:
  - gke-fleet # the namespace we want gke-fleet crs to live in
  secretRef:
    name: gke-fleet-sa-token # the token the operator will use in that namespace, ensuring permissions are only scoped to the project
    namespace: gke-fleet

This creates a ServiceAccount for the dummy gke-fleet-fleet@plural.sh email and plumbs that service account in as the writer for the gke-fleet Project. Finally, it binds that service account's access token as the credentials for the gke-fleet namespace.