Privileged access architecture

This page describes the path of a privileged connection and the pieces that make it up. Use it to plan the deployment and to explain to your network team why no ports need to be opened.

A single path to every machine

The person requests access in the console and connects with a ticket that works only once. The broker holds the connection while Ironchip checks the device, safe zone, risk and approval; only then does it inject the credential and start recording.

Piece	What it does	Where it runs
Person	Connects from the browser or with their client: ssh, psql, mysql, RDP, VNC, kubectl	Their device
Admin console	Accesses, factors, approvals, location, risk and recordings. It is the same console as the rest of the platform	Ironchip
Ironchip PAM broker	The only entry point: holds every connection, injects the credential and records the session	Ironchip
Secret store	Encrypted credentials and secrets, each company in its own space. The broker reads them and keeps no copy	Ironchip
Agent (optional)	osquery reports processes, accounts and exposure; the enforcer decides sudo and AppLocker and rotates local accounts	Your machines
Target machines	Servers, desktops, databases, Kubernetes and web applications	Your network

What happens on every connection

1. The person requests access in the console, in My access, with a reason if the policy requires one.
2. They connect with a single-use ticket, from the browser or with their own client.
3. The broker holds the connection and asks Ironchip: window or permanent access, address, factors and, if approval happens on connection, approval.
4. If admitted, the broker reads the credential from the store. The person never sees it.
5. The broker opens the session and records it from start to finish.
6. The agent reports and receives rules over HTTPS. With Ironchip Connect, your network opens no inbound port.

Ironchip Connect

Ironchip Connect is a lightweight connector installed inside each site. It opens an encrypted outbound tunnel (WireGuard) to Ironchip, and the broker reaches your machines through that tunnel and that tunnel only.

• No inbound traffic. Your network publishes no port: the connector only opens outbound connections.
• Your ranges, without conflicts. Even if another company uses the same private addresses, each site goes through its own tunnel.
• Direct when possible. If the network allows it, the tunnel is direct; if not, it goes through a relay without losing encryption.

Secret store

The store keeps all the credentials Ironchip PAM holds encrypted, each company in its own space. The platform database only keeps the description of each item, never the secret. The same store serves:

• Resource credentials, which the broker reads when connecting, and the passwords Ironchip manages and rotates.
• Checkouts and break-glass, to hand over a machine’s password with a reason and a record, and rotate it when it is returned.
• Team passwords. A manager for what people do need to know, such as a branch office router. Passwords are shared with people and groups, and every reveal is logged.
• Secrets for applications. Compatible with the Vault API: your code and your continuous integration read their secrets from Ironchip without changing a line.
• Short-lived credentials for AWS, Google Cloud, Azure and databases, created on request and removed automatically.

See Credential vault.

More information

• Just-in-Time sessions
• Credential vault
• Agent on the machines
• Resources