-
Notifications
You must be signed in to change notification settings - Fork 83
Remove K8s Auth Requirement From Docs #1053
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove K8s Auth Requirement From Docs #1053
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove the .idea
files? They are user specific and should not be pushed up to the repo
content/vault/v1.20.x/content/docs/updates/important-changes.mdx
Outdated
Show resolved
Hide resolved
Co-authored-by: Yoko Hyakuna <[email protected]>
@jaireddjawed If we're updating the current docs, the PR should merge to main instead of the release branch :) |
Sounds good. I'll open another PR. |
We recommend configuring an audience value for Kubernetes authentication roles when possible. | ||
This enables Vault to validate that the aud (audience) claim in JWT tokens is explicitly intended for Vault, | ||
reducing the risk of token misuse by other services. While not required, setting an audience is considered a security | ||
best practice and is encouraged when it doesn't interfere with your workflow. For example, tokens created using | ||
kubernetes.io/service-account-token do not include an aud claim, so it's appropriate to omit the audience field in this case. | ||
Here's an example configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We recommend configuring an audience value for Kubernetes authentication roles when possible. | |
This enables Vault to validate that the aud (audience) claim in JWT tokens is explicitly intended for Vault, | |
reducing the risk of token misuse by other services. While not required, setting an audience is considered a security | |
best practice and is encouraged when it doesn't interfere with your workflow. For example, tokens created using | |
kubernetes.io/service-account-token do not include an aud claim, so it's appropriate to omit the audience field in this case. | |
Here's an example configuration. | |
There are cases where configuring audience details can interfere with your | |
workflow. For example, tokens created using `kubernetes.io/service-account-token` | |
do not include an aud claim. But we recommend configuring an audience value for | |
Kubernetes authentication roles whenever possible. Setting explicit audience | |
details is best practice because it reduces the risk of token misuse by other | |
services. Vault can use the configured values to validate that the `aud` | |
(audience) claim in JWT tokens is intended for Vault. | |
For example: |
Style correction: avoid "this" as a pronoun, avoid possessives
Opened a new PR here. |
We no longer plan to require audiences in the kubernetes auth plugin. It was later discovered that doing so could break some valid configurations of our customers (more details here).
Instead, we plan to simply recommend that customers specify an
audience
if it does not break their workflow. We log a warning in Vault when an audience is not configured so that customers will be aware.