Allowlist for mission-critical workloads

[v0lkan]

Current situation:

When we define a ClusterSPIFFEID for a workload, VSecM essentially trusts it.

From VSecM’s vantage point

"spiffe://vsecm.com/vsecm/workload/keycloak/n/traffic-steering-1122334455/ns/rapps/sa/traffic-streering-rapp-sa"

and

"spiffe://vsecm.com/vsecm/workload/keycloak/n/keycloak-1122334455/ns/vmware-rms/sa/keyckloak-sa"

are entitled to the same secret.

That is okay if you control the cluster yourself.

But if the first spiffe id (traffic-steering app) is a third party app, and in its helm chart there is a poisoned clusterspiffeid, and that clusterspiffeid skips you inspections and gets deployed to the cluster, then it can impersonate keycloak (a workload that it is not entitled to access)

The simplest way to mitigate this is to have a pattern based allow list, similar to this:

{
"keycloak": "spiffe://vsecm.com/vsecm/workload/keycloak/n/*/ns/vmware-rms/sa/keycloak-sa"
}

so, if the name of the workload is "keycloak" then its spiffe Id will have to match the pattern for VSecM to admit it.

Whenever VSecM Safe establishes a connection and finds a workload that’s in the allow list, it will do a deeper pattern match based on the allow list.

The patterns will be part of a config map that the cluster administrator will enter off-cycle.

Also VSecM components will have its own patterns too so that no one can impersonate sentinel for example.

[v0lkan]

To make this happen, we’ll need an admission controller to ensure that the ClusterSPIFFEIDTemplate of the ClusterSPIFFEID of these workloads adheres to a strict pattern and it interpolates names, namespaces, and serviceaccounts of the workloads into the clusterspiffeid

[v0lkan]

update: instead of this; it is best to not allow third party apps create clusterspiffeids.

As their name imply, ClusterSPIFFEIDs are cluster-wide, and they should be managed by cluster admins.

Allowing a third-party app a cluster-level resource creation right is privilege escalation.