Skip to content

Allow providing additional audiences with the k8s auth configuration #6666

@andrey-dubnik

Description

@andrey-dubnik

Hi,

We are using vault (deployed externally to any clusters) k8s backend for quite a few things and everything we need so-far works fine. This includes using the service account to retrieve vault token and use it to retrieve vault secrets. Unfortunately cert manager does not work with the Vault in the same way we use it for other products and our experience is very much aligns with the issue ((Cluster)Issuer with vault auth and serviceAccountRef is not accepted by cluster due to audience · Issue #6150 · cert-manager/cert-manager (github.com)). The issue is down to the cert-manager forcing a specific aud on the token and vault looking for the kubernetes host aud being present (likely for all the good reasons). I have made few tests with the different audiences for the SA token and it works when the token aud matches the k8s host (in our case this is AKS public endpoint). We did not provided the aud with the Vault k8s auth backend while creating the role so this seem happens by default.

If cert-manager would allow providing additional audiences with the k8s auth configuration on top of the ones generated by default it will unblock the issue. I have also went through the original PR which introduced the change (The vault issuer can now be given a serviceAccountRef instead of relying on static service account tokens by maelvls · Pull Request #5502 · cert-manager/cert-manager (github.com)) but couldn’t figure the exact scenario where the service account gets exploited as attacker have to be in the same namespace and/or under the privilege to be able to create/access the token which is more or less game over to start with + vault has to have very relaxed policies for it to happen.

Describe the solution you'd like
Allow providing additional audiences with the k8s auth configuration

Describe alternatives you've considered
Creating additional JWT backend to the k8s auth backend. This is a duplicate automation required just for the cert-manager as rest services can interact with Vault using the service-account, hence we really like to unify the integration method on our end if possible.

I can open a PR for adding audiences to the k8s auth and the change is relatively simple but not sure if this does align with the project vision completely. If anyone could suggest if this works it would be great.

/kind feature

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions