Common use case

Access a private Kubernetes API directly

Keep kubeconfig pointed at the real private control-plane endpoint while WireZTNA supplies the required routes and split DNS.

Short answer

For operators, run wireztna connect and use the private API hostname in kubeconfig. Kubernetes authentication and RBAC continue to govern every action.

The problem

Remote operators and pipelines still need a path to a private control plane. A broad VPN may also expose nodes, databases, and internal load balancers.

Choose and scope the connection model

Authorize the operator's group for the Kubernetes publisher. Use an effective restricted rule for the API /32 and TCP 6443 when other systems in the CIDR must remain unreachable.

  1. 1Deploy a publisher that can reach the private Kubernetes API and expose its containing CIDR.
  2. 2Assign the operator through a group authorized for that publisher.
  3. 3Add an effective restricted AccessRule for the API /32 and TCP 6443 when endpoint-level enforcement is required.
  4. 4Run wireztna connect, keep kubeconfig on the private hostname, and use the normal Kubernetes identity.

Example access flow

Consumer

Operator with the full client

Client command

wireztna connect

Private destination

https://k8s-api.internal:6443

Authorization boundary

Effective API /32 and TCP 6443 rule; Kubernetes RBAC controls actions

When this pattern fits

  • An operator needs kubectl access through the control plane's real private name.
  • A trusted privileged runner can use the full client for deployments.
  • An ephemeral job can use a separate wzctl pass with explicit TLS configuration.
  • Kubernetes authentication, RBAC, admission controls, and audit logging are already configured.

Security boundary and limitations

  • Without an effective restricted rule, the full client routes the publisher CIDRs authorized through the operator's groups.
  • WireZTNA does not replace kubeconfig security, client identity, RBAC, admission policy, TLS, or Kubernetes audit logs.
  • A wzctl pass for CI may require the original TLS server name because the certificate usually names the private API hostname.

Frequently asked questions

Does kubectl use localhost with the full client?+

No. Keep kubeconfig pointed at the private Kubernetes API hostname or IP. The client provides the route and split DNS.

Can CI use wzctl instead?+

Yes, for one exact API IP and TCP port. Supervise wzctl and preserve the original TLS server name for certificate validation.

Does WireZTNA replace Kubernetes RBAC?+

No. WireZTNA controls reachability. Kubernetes authenticates the identity and authorizes resources, namespaces, and verbs.

Put this pattern into practice

← All use cases