Skip to content
This repository has been archived by the owner on Mar 22, 2024. It is now read-only.

Add option to toggle "skip_kubelet_verification" flag for k8s workload attestor #126

Closed
LaithLite opened this issue Mar 15, 2023 · 9 comments · Fixed by #243
Closed

Add option to toggle "skip_kubelet_verification" flag for k8s workload attestor #126

LaithLite opened this issue Mar 15, 2023 · 9 comments · Fixed by #243
Assignees
Labels
enhancement New feature or request

Comments

@LaithLite
Copy link
Contributor

The Spire-Agent sub-chart currently has the hard-coded line skip_kubelet_verification = true for its k8s workload attestor.

@faisal-memon
Copy link
Contributor

what kind of additional config do we need to verify kubelet? Ive never run with that setting.

@kfox1111
Copy link
Contributor

I think the plugin config stuff we've been talking about could handle this override? will likely need other config as well to work such as including the ca that signed the kubelets.

@marcofranssen marcofranssen added the enhancement New feature or request label Mar 17, 2023
@marcofranssen marcofranssen added this to the 0.7.x milestone Apr 4, 2023
@azdagron
Copy link
Member

azdagron commented Apr 4, 2023

I personally feel like skipping kubelet verification is the wrong default. As a project, we should aim for secure-by-default. If someone needs to disable that (because they are running in minikube) then they should be the special case.

@kfox1111
Copy link
Contributor

kfox1111 commented Apr 4, 2023

@azdagron I agree, except that there has been an open issue about it in kubeadm for ages.It is the norm, not the exception. :/
kubernetes/kubeadm#1223

Honestly, I'd like to see the spire team work with the kubelet team and add spire support to kubelet, so that kubelet server/client certs are from spire itself. This would go a very long way to solve a very old Kubernetes problem.

@faisal-memon
Copy link
Contributor

I personally feel like skipping kubelet verification is the wrong default. As a project, we should aim for secure-by-default. If someone needs to disable that (because they are running in minikube) then they should be the special case.

Valid point. But still the first interaction most people will have with this project is through minikube or docker desktop. Id like it to work out of the gate on those platforms to ensure a good user experience. And then have guides for more production scale deployments.

@kfox1111
Copy link
Contributor

I think it might be good to add some warnings in the generated notes if the value is true though? Lets the user know there may be a problem. They can then choose to ignore it if they think it is not a problem, or they will know it needs fixing?

@azdagron
Copy link
Member

Is there a "so you want to run this in production? here's what to consider" checklist anywhere? I'm with @kfox1111, the louder we can be about this kind of stuff, the better.

@kfox1111
Copy link
Contributor

So far, we've been putting all the recommended settings in examples/production/values.yaml that the user can directly include. This is one of the first that we can't really do a setting but need the user to consider some things.

So, would the checklist being in the generated NOTES work better, as it can be generated to include/exclude things based on the users actual specified values, or should it be outside of the chart where it may get a bit more visibility?

@kfox1111
Copy link
Contributor

I could take a stab at a NOTES patch, but I think it probably should depend on #166. Would greatly simplify the checks if it could verify global.spire.profile[x].production was specified.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants