Code change:
This is a Bug Report Problem: The konnectivity docs: Include the following instruction: Setting to doesn't seem right: This will break authentication for all tokens that use the default audience value (taken from the value), which is most tokens. This will allow tokens with in them to authenticate directly to kube-apiserver. I don't think we want that. Instead, we should just depend on konnectivity-server specifying the right audience in . Also: is unlikely to be a valid value for . In practice is typically an URL. Proposed Solution: Instead of including incorrect flag values inline, just link out to the correct documentation at Page to Update:
/triage accepted
/assign cheftako
GitHub didn't allow me to assign the following users: jkh. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign jkh Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign jkh52
/cc
Hi thanks for pointing this out. I just wanted to link this issue with the unfinished discussion in BTW, wouldn't it be more correct to specify both audiences: - where is value for the cluster Please correct me if I'm wrong but do you suggest to specify already existing audience for konnectifity-server, eg. this one which is used in kubeadm clusters by default: - where is value for the cluster Agree on that. I have the following setup in my project right now: I'd like to change it to be more correct. Based on said above. I suppose we have few more options: All three configurations are working, now we need to choose the most correct one. Of course we can link to the documentation page, but as for now it has no any usable examples to allow user simple start using this. I'm not big fan of leaving user without proper examples because they will just start using random configuration which works. Let's define correct defaults instead. Other services (eg. istio, vault) can rely on this configuration snippets as well. From my point of view option C is the most correct, what do you think?
The audience is meant for the konnectivity server, not kube-apiserver directly, correct? In other words, seems like those tokens should require proxying through the konnectivity server, kube-apiserver shouldn't accept them directly? ( this was the impression I got in our offline conversation - did I get that right?) I'm suggesting we can probably just leave unset and let it inherit from .
This is what I'm proposing:
Okay this is option B, but this way we would need to configure konnectivity-server with the flag: And konnectivity-agent with the volume: would it be correct configuration, or maybe better to use separate audience (option C)?
My current understanding is that we can use , since the konnectivity-server can tell kube-apiserver which audiences to validate against when it makes the request, and those apparently don't have to match kube-apiserver's :
I agree that we should link to the canonical documentation for setting up service account token issuer vs copying it here. These are now required flags so widespread adoption is imminent. We should leave Konnectivity server configured with . This means that Konnectivity server identifies as and will only accept tokens that are meant for audience . We shouldn't add to kube-apiserver, because we don't want kube-apiserver to accept tokens meant for connectivity server. Looking at the other docs, we likely don't have enough documentation on how to pick a value for . isn't great. is slightly better. Ideally, this is a globally unique URL (i.e. no private DNS or IPs) that supports OIDC discovery. In GKE, this is something like for in project in location . EKS is something similar.
Oh, got it! I don't remember exact reason why I started using this flag, but I just checked and confirm that it is working fine without it. Suppose it was just a configuration mistake. I'll prepare PR to fix this.
/assign
Hi, I was copied in. How can I help?
you're member of , we need an approval for to get it merged.
Best thing usually is to contact the if a review is urgent / not happening. Although, this week I'm sharing cover for that. So, consider me informed. I'll take a look.

Related discussion:
text: and direct the network traffic to the cluster nodes: 1. Make sure that <del> the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. You can enable [service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) by providing the following flags to the kube-apiserver: ``` --service-account-issuer=api --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --api-audiences=system:konnectivity-server ``` </del> <ins> [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) feature enabled in your cluster. It is enabled by default since Kubernetes v1.20. </ins> 1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`. 1. Set the `--egress-selector-config-file` flag of the API Server to the path of your API Server egress configuration file.