Add spiffe:svid selector

[kfox1111]

Pull Request check list

• Commit conforms to CONTRIBUTING.md?
• Proper tests/regressions included?
• Documentation updated?

Affected functionality
When you setup a node alias, it is difficult to match the workload without carefully looking at the documenation of the particular node attestor and see what selectors are unique. This is very hard to automate.

Description of change
Allow easy automation by making the node svid always available as a selector.

[sorindumitru]

If you know the node SPIFFE ID can you not just create the registration entry with the parent id set to the node SPIFFE ID?

[kfox1111]

If you know the node SPIFFE ID can you not just create the registration entry with the parent id set to the node SPIFFE ID?

No, because a node alias needs the parent id to be spiffe://<trustdomain>/spire/server.
workloads have parentid's that are node spiffe ids.

[sorindumitru]

@kfox1111 could you share an example of how this would be used?

[kfox1111]

The exact use case is complicated, but reasonable. I'll try and lay it out

Say you want to use a stronger node attestor then the k8s one. For example, you want to attest with a TPM and are running them as VMs in the cloud. It is very hard before hand to determine what the TPM pubhash is going to be. let alone have a helper app understand that a node spiffeid of spiffe://<trustdomain>/spiffe/attestor/tpm/:xxx will map to seelctor tpm:pub_hash:xxx

for spire-controller-manager to map a pod (workload) to the parentid of the node it is on, it only has access to the k8s node document that the pod is running on. In addition, lots of properties of the node object are directly controllable by the node itself so are untrustworthy.

While the parentid setting is templated in spire-controller-manager, the limited set of data it can use to do the template means its best to set it to something simple and trustworthy. like spiffe://{{ .TrustDomain }}/spire/controller-manager/{{ .Node.MetaData.UUID}}

so, how do we autogenerate a link between what spire-controller-manager needs as input entries and the unknown spiffeids nodes are going to get?

Node aliases can really help with this.

We write a helper client/server pair. How does this work:

1. the client runs on each node with a kubelet. it connects to the server using the node svid and passes a current k8s psat for its daemonset/serviceaccount.
2. the server accepts connections secured with valid spiffe svids. it accepts the k8s psat and verifies its valid for the current k8s cluster, from the right serviceaccount/daemonset, and extracts the node name from the token. It then creates/updates a ClusterStaticEntry of the form:

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterStaticEntry
metadata:
  name: node-{{ .Node.MetaData.UUID }}
  ownerReferences:
  - apiVersion: v1
    kind: Node
    name: {{ .Node.MetaData.Name }}
    uid: { .Node.MetaData.UUID }}
    blockOwnerDeletion: true
    controller: false
spec:
  parentID: spiffe://{{ .TrustDomain }}/spire/server
  spiffeID: spiffe://{{ .TrustDomain }}/spire/controller-manager/{{ .Node.MetaData.UUID}}
  selectors:
  - svid:path:<path from node's real svid>

the spire-controller-manager will sync these entries automatically to the spire-server, so the rest service does not need access to the spire server directly, increasing security. validating policies can also be written to further restrict what it can do for increased security.

Because it uses the svid:path, it can be made to work no matter what node attestor is being used on that particular node, nor does the node id needs to be discovered beforehand, or special knowlege of how to map a particular node svid to a set of selectors that works for that particular type of node attestor.

now you have a valid trust path from a pod all the way to a specific node attestor on the node it is running on, without human intervention, so stuff like autoscaling of k8s cluster nodes running in aws secured with tpms "just works".