Controller to reject aegis-managed SVIDs that don't conform a certain template.

[v0lkan]

A typical Aegis workload SVID is in the following form:

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: aegis-workload-demo
spec:
  spiffeIDTemplate: "spiffe://aegis.z2h.dev/workload/aegis-workload-demo/ns/{{ .PodMeta.Namespace }}/sa/{{ .PodSpec.ServiceAccountName }}/n/{{ .PodMeta.Name }}"
  podSelector:
    matchLabels:
      app.kubernetes.io/name: aegis-workload-demo
  workloadSelectorTemplates:
  - "k8s:ns:{{ .PodMeta.Namespace }}"
  - "k8s:sa:{{ .PodSpec.ServiceAccountName }}

However, as of now, there is nothing preventing and administrator from interpolating the meta information themselves and coming up with an ID like:

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: aegis-workload-demo
spec:
  spiffeIDTemplate: "spiffe://aegis.z2h.dev/workload/aegis-workload-demo/ns/someone-elses-namespace/sa/someone-elses-service/n/some-other-pods-name"
  podSelector:
    matchLabels:
      app.kubernetes.io/name: aegis-workload-demo
# workloadSelectorTemplates:
# no workload selector templates at all.

Although you still need sufficient admin privileges to do this; it is better to safeguard against that.

Acceptance Criteria

• Create a Kubernetes Controller (aegis-notary) that checks all the generated ClusterSPIFFEIDs and if any of them have the spiffeIdTemplate that begins with spiffe://aegis.z2h.dev/workload (customizable) verify that the rest of the template is in the expected format.
• If there is a problem, log it and delete cluster spiffeid.
• If everything is fine, allow the ClusterSPIFFEID creation.

[v0lkan]

Note that this Controller is a “nice to have”, but not mandatory.

ClusterSpiffeIDs shall be only created by the authorized admins in the first place.

The controller can periodically check and rectify any misconfigurations and/or delete ClusterSPIFFEIDs that do not conform a standard.

[v0lkan]

Note that instead of a custom operator, we can use an admission webhook as a gatekeeper:

https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

[v0lkan]

Punting to 1.1.0 as this is important, yet less urgent.

[v0lkan]

This can be a starting point for other controller-related tasks.

[v0lkan]

Counter point: This is not about security; since an administrator can very-well disable the controller too. It is more about “convenience”.

And for convenience, instead of running yet another process all the time inside the cluster, maybe an offline schema validator would be more useful.

A validator that

• checks injected AEGIS_xxx environment variables and make sure that they don’t have typos and validation problems.
• checks yaml manifests and ensure that there is nothing out of the ordinary with them.
• etc.

There are several tools that can be used to facilitate such an offline validation:

• https://www.conftest.dev/install/
• https://github.com/cloud66-oss/copper
• https://stelligent.github.io/config-lint/#/example-rules
• https://www.kubeval.com/

We can pick one that fits best to our needs, and create a validator app that you can run before each deployment.