Hello !
I have the following use case. I have a Vault Cluster that runs on EC2s. Users log in to Vault via OIDC with Google. We have several Kubernetes Clusters that use Vault Secrets Operator with the Kubernetes VaultAuth and this works well. However, we want developers to be able to mimic the behavior they would have on the Kubernetes clusters locally with solutions like Minikube. This would allow them to test their code with the VaultStaticSecrets manifests locally and simply.
The issue I currently have is on how to achieve this without having to create specific resources on the Vault Cluster. For example the VaultAuth Kubernetes and JWT method require adding the Minikube’s certificate in the Vault Cluster.
What I had in mind was for users to login via CLI with our OIDC provider (vault login -method=oidc role="google_sso"
) and just set the fetched token in the VaultAuth manifest and be able to access secrets with their own permissions.
Is this in any way posible ? I wasn’t able to make it work with the JWT method and I don’t know how far I am from reality 
For example I had this kind of manifest:
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
name: test-auth
namespace: test
spec:
method: jwt
jwt:
role: google_sso
secretRef: jwt-secret # Contains the token fetched from the CLI Vault login command
tokenExpirationSeconds: 3600
vaultConnectionRef: test/default
Thank you for the help !
To summarize, you want some workload (in this case a k8s pod) to be able to make API/CLI calls to Vault from a Kubernetes cluster not necessarily configured with Vault?
If this is truly for development purposes, token and approle auth method comes to mind as auth methods that require less configuration?
Similarly, if just for testing purposes, someone could start Vault in dev mode which runs in memory so its just temporary.
To summarize I would like to allow developers to test VSO manifests locally (for example a VaultAuth + VaultStaticSecret) with real Vault data.
However, I would have liked for them to be able to do so without having to manually allow their local cluster (via the cluster certificate). That is why I had the user’s OIDC token in mind as a way to try to authenticate to Vault with VSO.
I could definitely look more into appRoles ! We never had the usecase yet and I have little knowledge on how it works but if I am not mistaking this would more or less require:
- Creating an appRole for each team with the adequate policy.
- Creating a secretID for their appRole.
- Making sure each team has access to fetch their secretID.
In that case they would be able to setup VaultAuth with appRole to connect to Vault. It just requires more initial configuration than just using their existing role they have with their OIDC role.
Thanks for clarifying - looking over the VSO docs, yea I think AppRole might be worth looking into.
The secretID I think need to be saved as a Kubernetes Secret, so as long as you have a secure mechanism to distribute that, I think it might work. Whats not clear is if there is still any cert requirements, but given that is for a trust between Vault and Kubernetes I would think not.
1 Like