Enforce access checks for brokers in the k8s workloadattestor

[matheuscscp]

Follow up for #6915. Now addressed directly in #6915

Before the Broker API k8s support is released, add two broker-aware behaviors to the k8s workload attestor:

1. Broker-originated Attest() and AttestReference() requests that ask for selectors for a Kubernetes object should run a Kubernetes SubjectAccessReview before returning selectors. The review should use the broker SPIFFE ID as the SAR username and no groups, allowing the Kubernetes authorizer to decide which objects each broker is allowed to reference.

2. Add a per-broker pod reference scope. The default should restrict pod references to the agent node: the referenced pod must have spec.nodeName matching the configured agent node name (node_name / node_name_env). A broader cluster scope should remove that same-node restriction, while still requiring the SubjectAccessReview check above.

[sorindumitru]

spiffe:///broker1 -> {username: broker1, groups: [flux-brokers]}

If I'm reading this right you are proposing to extract the username of the broker from the SPIFFE ID of it? I don't think you can expect the broker SPIFFE ID to have known format, this will depend on the deployment.

I think this would need to be done from the workload attestation plugin, which doesn't currently receive the caller SPIFFE ID. We'd have to pass it through to it somehow.

[matheuscscp]

If I'm reading this right you are proposing to extract the username of the broker from the SPIFFE ID of it?

Not at all. I'm proposing a configuration API for the plugin:

Let's add a mapping from broker ID to Kubernetes usernames and groups in the agent's plugin config

broker1 in the SPIFFE ID and in the Kubernetes username is just a coincidence, sorry

[matheuscscp]

We'd have to pass it through to it somehow.

One way is using the ctx, what do you think?

[matheuscscp]

I have a very specific implementation in mind and it's quite simple. I'm going to open a quick draft PR using the main Broker API PR as base, should help the discussion

[matheuscscp]

@sorindumitru I filed this draft against the main PR in my fork:

matheuscscp#1

[matheuscscp]

After the recent requirements for Istio were added, I think this issue should be addressed in the main PR.