Can Vault Roles be passed from the VaultSecret object itself about vault-secrets-operator HOT 6 CLOSED

I would say it's more of a feature request,
and this is one of the most useful as well since not many people would use the same role for the whole cluster.
but this might provide them an option to override the default role used. (in this case vault-secrets-operator)

is it possible that when the operator on-demand pulling the secrets, we can pass a different role?
and by default for the operator to run we can have vault-secrets-operator as usual, to which we can give very minimal permission.

TL;DR everything would be the same,
just that, role passing through the VaultSecret will be overridden while pulling that particular secret.

E.g:

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: {{ .Chart.Name }}-secrets
  namespace: {{ .Release.Namespace }}
spec:
  role:   NewRole
  path: "{{ .Release.Namespace }}/{{ .Chart.Name }}"
  type: Opaque

In this case, NewRole will be used while pulling the secret from "{{ .Release.Namespace }}/{{ .Chart.Name }}" path.

from vault-secrets-operator.

Hi @saikatharryc, I looked a bit deeper into this and If we found a good way to implement this, we can do it. Before we start implementing this I would clarify the process, so that we are on the same track.

We enable the Kubernetes auth method and tell Vault how to communicate with the Kubernetes cluster:

vault auth enable kubernetes
vault write auth/kubernetes/config token_reviewer_jwt="$SA_JWT_TOKEN" kubernetes_host="$K8S_HOST" kubernetes_ca_cert="$SA_CA_CRT"

No we are creating different roles with different policies:

# Create default role and policy, which is only needed to not introduce a breaking change or we have to bump the major version:
vault write auth/kubernetes/role/vault-secrets-operator bound_service_account_names="vault-secrets-operator" bound_service_account_namespaces="$VAULT_SECRETS_OPERATOR_NAMESPACE" policies=vault-secrets-operator ttl=24h

# Create fine granular roles:
# myrole1 can access everything under the 'foobar' path
vault write auth/kubernetes/role/myrole1 bound_service_account_names="vault-secrets-operator" bound_service_account_namespaces="$VAULT_SECRETS_OPERATOR_NAMESPACE" policies=mypolicy1 ttl=24h
# myrole2 can access everything under the 'helloworld' path
vault write auth/kubernetes/role/myrole2 bound_service_account_names="vault-secrets-operator" bound_service_account_namespaces="$VAULT_SECRETS_OPERATOR_NAMESPACE" policies=mypolicy2 ttl=24h
# myrole3 can access everything under the 'abcxyz' path
vault write auth/kubernetes/role/myrole2 bound_service_account_names="vault-secrets-operator" bound_service_account_namespaces="$VAULT_SECRETS_OPERATOR_NAMESPACE" policies=mypolicy2 ttl=24h

Now we can use the operator and we are creating the following secret:

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: test
  namespace: default
spec:
  role:   myrole1
  path: foobar/test
  type: Opaque

The operator reconciles the new secret and sees that he should use a different role for this secret. So before pulling the secret we have to authenticate against Vault under the path where the auth method was enabled (VAULT_KUBERNETES_PATH), the mounted ServiceAccount token from /var/run/secrets/kubernetes.io/serviceaccount/token and the role myrole1:

vault write auth/kubernetes/login role= myrole1 jwt=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

Here we could reuse the implementation from the vault.go file, but maybe we can skip the renewing of the token to make the implementation easier and to only allow very short lived tokens:

With the returned Vault token we get the secret as usual.

Is this the way you had in mind?

from vault-secrets-operator.

Hi @saikatharryc,

I'm not sure if this is possible, because we have to provide the policy during the setup of the operator. When we create the role with the following command:

vault write auth/kubernetes/role/vault-secrets-operator \
  bound_service_account_names="vault-secrets-operator" \
  bound_service_account_namespaces="$VAULT_SECRETS_OPERATOR_NAMESPACE" \
  policies=vault-secrets-operator \
  ttl=24h

from vault-secrets-operator.

from vault-secrets-operator.

Hi @saikatharryc, it is now possible to set the Vault Role via the vaultRole property in the VaultSecret.

The new 1.11.0 release contains this feature.

from vault-secrets-operator.

Thanks a lot! I will test this out.

from vault-secrets-operator.