> For the complete documentation index, see [llms.txt](https://docs.p0.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.p0.dev/readme/connectors.md). # P0 connectors 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
Diagram showing the P0 connector inside the customer's cloud trust boundary, alongside KMS and secrets manager and existing cloud-native paths, between the P0 control plane and the target fleet
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.
Sequence diagram of an SSH request: generate ephemeral keypair, request access and justification, evaluate policy and approval, sign public key, verify cert and fetch host credential, then log in and start the session
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.
Diagram comparing the cloud-native path, which needs an in-host agent and breaks if it dies, with the connector path, which needs sshd and network and survives agent failure
| Failure mode | Cloud-native path | Connector path | | ----------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------ | | 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)). *** ## 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 `sudoers` policy 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](/integrations/resource-integrations/google-cloud/security-perimeter.md) and the [Microsoft Entra ID security perimeter](/integrations/directory-integrations/microsoft-entra-id/viewing-security-perimeter-logs.md) are the IAM-layer connectors for those clouds. * The [Azure jump host management connector](/integrations/resource-integrations/microsoft-azure/jump-host-management.md) dispatches privileged session commands to your jump host VMs. * The PostgreSQL and MySQL integrations deploy a `p0-connector` to broker database grants. See [Installing an RDS database](/integrations/resource-integrations/postgresql-new/installing-an-rds-database.md). *** ## 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](/integrations/resource-integrations/google-cloud/security-perimeter.md): Install the IAM-layer connector for GCP. * [Viewing Security perimeter logs](/integrations/directory-integrations/microsoft-entra-id/viewing-security-perimeter-logs.md): Read the Entra security perimeter connector's logs. * [Azure jump host management](/integrations/resource-integrations/microsoft-azure/jump-host-management.md): Configure the jump host connector. * [Just-in-time access](/readme/just-in-time-access.md): The access model connectors broker.