Code change:
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.

Related discussion:
text: 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.