unsupportedBuiltInPlugins - nodeAttestor x509pop

[mrod23]

# NOTE: This is unsupported and only to configure currently supported spire built in plugins but plugins unsupported by the chart.
# Upgrades wont be tested for anything under this config. If you need this, please let the chart developers know your needs so we
# can prioritize proper support.
## @skip unsupportedBuiltInPlugins

Feature request to add support for nodeAttestor support for spire-agent.
x509pop is an easy way to get the spire-agent-upstream connected with a spire-server that sits outside Kubernetes. It would be nice to have official support for x509pop on the spire-agent.

Also, I've only used helm a few times in the past, but I'm open to learning and contributing to the project.

[kfox1111]

Hi @mrod23, thanks for filing the issue.

There are some devils in the details here....

Have you tried it yet with the unsupportedBuiltInPlugins? I'm curious if some of the other constraints can be overcome. In particular, I don't believe the k8s workload attestor works without the k8s node attestor. and you cant have more then one node attestor enabled on an agent. So attesting the nested spire (assuming thats what your trying to do) might be a little tricky on the workload side if using an x509pop node attestor. Still may be possible if your nodes are static but maybe pretty problematic on a cloud based k8s?

Probably more discussion/experimentation would be needed to flesh out all the details. Could you please provide more information about what you are trying to do?

[kfox1111]

I just got some confirmation that you can use x509pop with k8s workload if you don't use the spire-controller-manager but manually register the workload with the right parentids in the upstream server.

[kfox1111]

Another constraint:

can you use the same x509pop cert with different nodes?

No, because using this attestor, the only thing we know about the node is the cert it presents. If you present the same cert twice, SPIRE sees it as the same node. So you’ll get this behavior with two on one node or two on two etc

so there is a 1:1 relationship between x509pop and spire node identity.

👍

[kfox1111]

There is a PR here spiffe/spire-controller-manager#289 that should enable the use case of managing the system with spire-controller-manager while using the x509pop node atttestor and k8s workload attestor.

[mrod23]

Thanks for the response here.
That's correct there is a 1:1 relationship between x509pop and spire node identity.

For production I think I'll use PSAT for NodeAttestation.
The reason I'm asking about adding X509Pop is because I'm currently testing out the Nested Cluster Helm chart deployment on my local PC. I have a test SPIRE server deployed in AWS that is acting as the root server. In order to connect, I'm manually updating the spire-agent-upstrem config map so it can use X509pop for node attestation. I can't use PSAT in this case, because the SPIRE server is unable to reach my local PC to hit the Kube API.

[kfox1111]

so, one node local cluster, with x509 pop for attestation of the downstream, and then nested spire for all the rest of the workload?

yeah, should be able to use the unsupportedBuiltInPlugins section on the upstream agent for now to prevent having to manually tweak the configmap, use the x509 cert loaded on the host with a hostpath extra volume/mount, and on the root server, don't use spire-controller-manager but manually setup entries for the downstream. I think that configuration should work for now for testing.

[mrod23]

thanks, will try that out

[faisal-memon]

@mrod23 Have you had a chance to look into this yet?

[mrod23]

I winded up not trying this.
I'm now testing on our development kubernetes cluster. It has nine nodes, creating nine different spire-agents. Each agent would need it's own cert to use the x509 auth.
I was able to get k8_psat auth working instead

[kfox1111]

When you say 9 different agents, do you mean 1 install of the chart with 9 different x509 certs, one per host,
or are you trying 9 different chart installs/daemonsets/x509 certs?

I think the first option would work.

[mrod23]

One install of the chart creates 9 different agents. Each agent needed it's own separate x509 cert.

…

On Thu, Feb 22, 2024, 09:54 kfox1111 ***@***.***> wrote: When you say 9 different agents, do you mean 1 install of the chart with 9 different x509 certs, one per host, or are you trying 9 different chart installs/daemonsets/x509 certs? I think the first option would work. — Reply to this email directly, view it on GitHub <#188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA46OSPKYGSBKXPOIFYLGM3YU5L2FAVCNFSM6AAAAABB5O2OZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZGYZDANJUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>