🧩P0 Connectors
Understand P0 connectors: stateless, versioned runtimes you deploy in your own cloud account to broker just-in-time access, so no standing credentials sit on laptops or in P0's SaaS.
A connector is a small piece of P0 software that runs inside your own cloud account and brokers just-in-time access to your infrastructure. It's the part that actually reaches your resources (signing in to a host, provisioning a database grant, and so on), so that neither your engineers' laptops nor P0's SaaS ever hold standing credentials to your fleet.
P0's default access paths are agentless and driven entirely by your cloud provider's native IAM. Connectors exist for the cases where that isn't enough: where a cloud-native path is fragile, where provider IAM limits what an external service can do, or where you want an access path that keeps working even when a managed agent, or P0 itself, is unavailable.
What a connector is
A connector is a minimal runtime you deploy in your own cloud account, a container (for example on Cloud Run or ECS) or a serverless function. It has a deliberately small surface:
It's the only component that holds credentials to your target fleet, and those credentials never leave your environment. Signing keys and per-host secrets live in your own KMS and secrets manager.
It's stateless, runs from a published, versioned image, and can scale to zero between sessions when deployed as a function.
It exposes no inbound interface other than a listener that mutually authenticates (mTLS) against P0's certificate authority.
It installs through P0's infrastructure-as-code as a one-line operation, and updates by bumping an image or module version.
Conceptually, the connector is your security perimeter running P0-authored logic. It sits inside your trust boundary rather than reaching in from outside it.
Where it sits
The connector lives next to your cloud-native paths, not in front of them. Adopting a connector doesn't remove SSM, Bastion, or OS Login. They keep working, and the connector is an extra route to the same hosts.
How a request flows
Using SSH as the worked example, a request for p0 ssh prod-web-01 looks like this. The same shape (request, approve, mint short-lived credential, hand it to the connector) generalizes to other resource types.
The important properties: the engineer's private key never leaves their machine; the certificate is short-lived; the signing material and per-host credentials stay in your cloud; and the connector, not the laptop and not P0, is the only thing that ever authenticates to the host.
Why we built connectors
1. A second, independent path in
This is the core motivation. A connector path needs only that sshd is running and the host is reachable on the network. It doesn't depend on an in-host agent or a managed access service, so it stays available across the failure modes that most often take the cloud-native path down.
In-host agent dies or won't start at boot
Blocked, often only fixable by re-provisioning the instance
Unaffected, if sshd is up
Managed access service degraded
Blocked
Unaffected
P0 control plane unreachable
Blocked
Can continue within policy, signing material already lives in your cloud
No network route to the host
Blocked
Blocked, a connector doesn't solve reachability
Because the connector and your signing material both live in your cloud, it's possible to define a break-glass path that keeps functioning even if P0's control plane is temporarily unreachable. Whether and how that's enabled is a policy decision made with your team.
2. Credentials never touch laptops, and never leave your cloud
The connector is the single mediator that authenticates to your fleet, and it reads its credentials from your own vault. Your engineers never own a credential to the target hosts, and neither does P0's SaaS. Per-host credentials are short-lived and rotate on a schedule you control.
3. It works within your IAM instead of around it
Running P0's logic inside your environment sidesteps the provider-IAM limits that would otherwise constrain what an external service can do, without granting P0 broad standing permissions. The connector operates with least-privilege, scoped credentials that stay in your account.
4. A minimal, consistent, up-to-date footprint
Every connector ships as the same kind of artifact: a small, stateless, published image installed through IaC and versioned centrally. That keeps the deployment story identical across integrations and makes staying current a version bump rather than a migration.
What a connector isn't not
Not a bastion or jump host. No human ever logs into the connector. It provisions access; it is not a machine you land an interactive session on.
Not a proxy in front of your cloud-native paths. It runs beside them as an independent route, and doesn't intercept or replace SSM, Bastion, or OS Login.
Not a fix for network reachability. You bring your own network path to the target host; the connector must be able to reach
sshd, but it doesn't create connectivity where none exists.Not a standing root account. The on-host principal it uses is tightly constrained (see the Security model).
Security model
There are two trust boundaries: between your engineer's machine and P0, and between P0 and your connector. Everything past the connector, its conversation with the fleet and with your vault, stays inside your cloud account.
The connector exposes no inbound surface except a listener that mutually authenticates against P0's certificate authority. It has no persistent state, and per-host credentials are short-lived and rotated on a configurable schedule.
The on-host principal. To bridge an external identity into a Linux session, the connector uses a dedicated system account on the target host (commonly seen as p0-user). Every product in this category has an equivalent privileged on-host principal (it is intrinsic to the problem), and P0 bounds it deliberately:
It is not a general-purpose root account. Its
sudoerspolicy enumerates only the specific commands it may run (ephemeral user provisioning and file operations on a fixed set of paths), or it is locked to a single signed bootstrap script that is integrity-checked at every invocation.It has no interactive shell. A try to land a shell as this account fails; only the permitted commands or bootstrap script run.
Every invocation is logged, both in the host's audit log and in the connector's stream to your SIEM.
Handled honestly: if that on-host principal were fully compromised on a host, an attacker could create or remove local users and change file ownership within the configured paths, but couldn't modify the integrity-checked bootstrap script, and couldn't pivot to other hosts, because credentials are per-host and short-lived. That's a materially smaller blast radius than a generic root SSH key. It's not zero, and we don't claim otherwise.
One integration, several connectors
A connector is a general primitive, not a single product. A given integration is usually a small constellation of cooperating connectors, each doing one job:
an IAM-layer security perimeter that manages cloud-native access,
an SSH connector for host access,
a database-engine connector that provisions grants over SQL,
a cloud-API connector that creates managed identities through a provider's admin API.
Keeping each piece separate and single-purpose is deliberate: every connector carries only the permissions it needs, and each can be validated independently. It also means a connector for a new system is a small, well-scoped addition rather than a change to everything around it.
You can see this pattern in the integrations that ship today:
The GCP IAM management security perimeter and the Microsoft Entra ID security perimeter are the IAM-layer connectors for those clouds.
The Azure jump host management connector dispatches privileged session commands to your jump host VMs.
The PostgreSQL and MySQL integrations deploy a
p0-connectorto broker database grants. See Installing an RDS database.
FAQ
Do my engineers connect to the connector? No. No human logs into the connector. It brokers access; it's not something you open a session against.
Does P0 hold credentials to my hosts? No. Signing keys and per-host credentials live in your own KMS and secrets manager. The connector reads them there, inside your account.
Do I still need SSM, Bastion, or OS Login? You can keep them. The connector runs alongside your cloud-native paths as an additional, independent route. It doesn't replace them.
Does a connector solve private-network reachability? No. You bring your own network path to the target; the connector must be able to reach the host, but it doesn't create connectivity.
What happens if a connector is compromised? The blast radius stays small: per-host credentials that are short-lived, no lateral movement to other hosts, no interactive shell on the on-host account, and full audit logging of everything it does.
Does access keep working if P0 is temporarily unreachable? It can, within policy. Because the signing material lives in your cloud, you can define a break-glass path through the connector that does not depend on P0's control plane being reachable. This is configured with your team.
How is a connector installed and kept up to date? Through P0's infrastructure-as-code, as a one-line install. Updates are an image or module version bump.
Related documentation
Google Cloud security perimeter: Install the IAM-layer connector for GCP.
Viewing Security perimeter logs: Read the Entra security perimeter connector's logs.
Azure jump host management: Configure the jump host connector.
Just-in-time access: The access model connectors broker.
Last updated