Connector CRD

Expanded Definition

A connector CRD is a Kubernetes custom resource definition that lets the Tailscale operator create and manage network-facing components as native cluster objects. In practice, it provides a Kubernetes API shape for resources such as subnet routers, exit nodes, app connectors, and SSH session recorder nodes, so operators can declare intent in YAML rather than manage each function as a separate external appliance.

The boundary to watch is that the CRD is not the network service itself. It is the control plane object that describes and reconciles the service inside Kubernetes. That distinction matters because the CRD inherits cluster lifecycle, admission, and RBAC behaviour, while the underlying Tailscale function still determines packet flow, reachability, and access path. For readers comparing Kubernetes extension patterns, the Kubernetes custom resources documentation is the most direct authority for how CRDs extend the API.

Guidance vs consensus: there is broad agreement that CRDs are the standard way to make domain-specific abstractions manageable in Kubernetes, but implementation choices differ on how much networking policy should be expressed in the CRD versus separate cluster policy objects.

Examples and Use Cases

Connector CRDs usually appear when a platform team wants to treat network connectivity as a repeatable cluster workload rather than a manually configured integration. That makes the object useful in environments where network reachability must be deployed alongside application changes.

• A cluster deployment exposes a private subnet through a subnet router Connector CRD so workloads can reach internal services without a standalone gateway appliance.
• An exit node Connector CRD provides controlled egress for selected pods or namespaces when traffic routing must be centrally managed.
• An app connector CRD publishes access to a specific internal application while keeping the application itself off the public internet.
• An SSH session recorder node CRD supports controlled administrative access and auditability for operations teams that need to observe privileged sessions.
• A platform team templates Connector CRDs in GitOps so changes to network functions move through the same review path as application manifests.

The main tradeoff is operational simplicity versus abstraction depth. A CRD reduces per-service manual setup, but it also concentrates responsibility in the operator and the Kubernetes control plane, so changes to the resource model can affect many dependent access paths at once.

Security Implications

Connector CRDs matter because they turn connectivity and access-adjacent functions into declarative cluster resources. If the CRD is misconfigured, a cluster may expose a subnet too broadly, route egress through an unintended exit path, or grant application access where segmentation was expected. Those are not just deployment errors; they are authorization and exposure problems that can alter the trust boundary of the whole cluster.

Mismanagement also creates governance drift. Because the resource sits inside Kubernetes, teams may assume the platform automatically inherits the same guardrails as workload objects, yet the network effect can be much broader than the object footprint suggests. The observable symptoms are often indirect: unexpected reachability, asymmetric traffic flows, or service access that no longer matches the intended namespace or environment boundary.

For operators, the practical warning sign is that a small YAML change can have a large blast radius. Any review process that treats the Connector CRD as a routine application manifest instead of an access-bearing network control will miss the real consequence.

Domain and Governance Relevance

Connector CRDs belong first to Kubernetes extension and network governance, not to identity security by default. Their security significance increases when they are used to control privileged routing, internal application exposure, or administrative access paths, because the CRD then becomes part of the trust model for who can reach what inside the cluster.

This is where NHIMG’s identity lens becomes materially useful. When a Connector CRD governs access to internal services, it affects how non-human workloads, operators, and automation obtain connectivity, and that changes the governance burden around ownership, review, and revocation. In other words, the CRD is not just a deployment object; it can become an access-control dependency for machine-driven operations.

That makes it relevant to cluster operators who need to align network intent, workload identity, and operational accountability. The core question is whether the CRD is merely describing a service, or whether it is also shaping durable access paths that need the same scrutiny as other privileged infrastructure changes.

Related resources from NHI Mgmt Group

• Should organisations use connector-less deployment for on-prem DSPM where possible?
• What do security teams get wrong about connector credentials in infrastructure automation?
• Why do third-party connector patterns create NHI risk even when tokens are refreshed automatically?
• How can organisations tell if connector coverage is actually sufficient?