![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Mar 9, 2026
\nKubernetes Operator ProxyGroupPolicy resourcesare currently in alpha. To try it, follow the steps below to enable it for your network using Tailscale v1.96 or later.
\nWhen managing a multi-tenant Kubernetes cluster, you may wish to limit access to your deployed ProxyGroup resources,\r\nespecially when those ProxyGroup instances use different tailnets. For operator versions 1.96, and later you can now\r\nuse the ProxyGroupPolicy resource that lets cluster administrators limit usage of the tailscale.com/proxy-group\r\nannotation on Service and Ingress resources within individual namespaces.
ProxyGroupPolicy resources let you specify whether a namespace can use a given ProxyGroup for ingress or egress.\r\nShould a user attempt to create an Ingress or Service that specifies a ProxyGroup's name that is not within\r\nthe allow list, it will be rejected by the Kubernetes API server.
A namespace that contains no ProxyGroupPolicy resource is effectively\r\nconsidered an \"allow-all\". When applying a ProxyGroupPolicy to a namespace that\r\nalready contains Service or Ingress resources using the\r\ntailscale.com/proxy-group annotation, these resources will not be evaluated until they are\r\nnext modified.
Below is an example of a ProxyGroupPolicy that limits access to all ProxyGroup resources, effectively a \"deny-all\"\r\npolicy:
apiVersion: tailscale.com/v1alpha1\r\nkind: ProxyGroupPolicy\r\nmetadata:\r\n name: deny-all\r\n namespace: example\r\nspec:\r\n ingress: []\r\n egress: []\nThe above ProxyGroupPolicy will be transformed into native ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding\r\nresources that evaluate the contents of the tailscale.com/proxy-group annotation on Ingress and Service resources\r\nwithin the same namespace.
If a namespace contains multiple ProxyGroupPolicy resources, they will be\r\nmerged into a single ValidatingAdmissionPolicy resource.
Imagine a multi-tenant Kubernetes cluster in which teams use separate tailnets for their services and each team is granted\r\na namespace within the cluster for their own personal workloads.
\nTo set up access to their respective tailnets a ProxyGroup resource is created for each team pointing to their personal\r\ntailnets. To ensure ingress or egress is not allowed to any other tailnets from those namespaces, a ProxyGroupPolicy\r\ncan be specified for each namespace:
apiVersion: tailscale.com/v1alpha1\r\nkind: ProxyGroupPolicy\r\nmetadata:\r\n name: billing\r\n namespace: team-billing\r\nspec:\r\n ingress:\r\n - billing-ingress\r\n egress:\r\n - billing-egress\r\n---\r\napiVersion: tailscale.com/v1alpha1\r\nkind: ProxyGroupPolicy\r\nmetadata:\r\n name: customer-engineering\r\n namespace: team-customer-engineering\r\nspec:\r\n ingress:\r\n - customer-engineering-ingress\r\n egress:\r\n - customer-engineering-egress\nThis then only lets Service and Ingress resources within the team-billing namespace use the billing-ingress\r\nand billing-egress``tailscale.com/proxy-group annotations. The following Ingress resource would then be rejected by\r\nthe Kubernetes API server:
apiVersion: networking.k8s.io/v1\r\nkind: Ingress\r\nmetadata:\r\n name: example-ingress\r\n namespace: team-billing\r\n annotations:\r\n tailscale.com/proxy-group: customer-engineering-egress\r\nspec:\r\n defaultBackend:\r\n service:\r\n name: example\r\n port:\r\n number: 80\r\n ingressClassName: tailscale\r\n tls:\r\n - hosts:\r\n - example\nThe same will also occur for any other ingress/egress methods the operator supports that rely on ProxyGroup resources.
Ask AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}