hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
30.85k stars 4.17k forks source link

Documentation consistency for "Kubernetes Auth" #13645

Open bitvijays opened 2 years ago

bitvijays commented 2 years ago

Dear Hashicorp Vault Team,

Hope you are doing well. Thank you for the amazing support and creating documentation for the same. We really appreciate it.

Recently, we want to create a Certificate Authority using Vault and issue certificates using cert-manager cluster-issuer in Kubernetes that requires creating a service account and ClusterRoleBinding for that service account.

I am afraid to say, it took my approx 3-4 days to do the same with good amount of debugging, googling, reading issues and what I am doing wrong whereas it's probably a 30 mins job .

The problem is a bit of miss in the documentation. For instance, for creating the CA and using cert-manager, there's a Configure Vault as a Certificate Manager in Kubernetes with Helm, now if we read this documentation. In the Configure Kubernetes authentication, there is a

vault write auth/kubernetes/config \
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
    token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    issuer="https://kubernetes.default.svc.cluster.local"
Success! Data written to: auth/kubernetes/config

Now, it is not exactly provided that which service account is /var/run/secrets/kubernetes.io/serviceaccount/token. A beginner like me just blindly copied the code and executed (I am not the only one). Now, later in section Configure an issuer and generate a certificate, we create a service account issuer that is ideally used for Kubernetes authentication, rather than the one that was mounted on the /var/run/secrets/kubernetes.io/serviceaccount/token in the vault-0 pod.

Now, here I was confused whether there are two service accounts - issuer and the default in either the default namespace or cert-manager namespace. Further, the above documentation fails to mention the ClusterRoleBinding required for the service account for Kubernetes Auth.

So, the result of following the above documentation kind of results into multiple people facing issues like Kubernetes Authentication Denied and Vault ClusterIssuer with Kubernetes authentication not possible?

Documentation Integrate a Kubernetes Cluster with an External Vault also doesn't mention anything about ClusterRoleBinding probably because helm would have installed it automatically (might be wrong).

Now, the best and proper documentation on Kubernetes Auth that solved my issue in 5 mins was Vault Agent with Kubernetes. It clearly mentions about process of Kube Auth, service account, TokenReviewAPI and ClusterRoleBinding. I followed this and was able to resolve the issue.

Suggestion

A minor suggestion I have is maybe we can structure the tutorials/documentation in a different way. For instance,

The benefit probably might be

Just sharing the thoughts, feel free to ignore.

Thank you again for your awesome support.

Kind Regards, Vijay

rdxmb commented 9 months ago

This is a point I've struggled also.

Indeed, the serviceAccountToken is not needed - at least when vault and the agent are running within the same kubernetes cluster. Have a look at this blog with a simplified method and detailed explanations: https://velocity.tech/blog/passing-secrets-using-vault-with-kubernetes