# Privileged access architecture

> Which pieces take part in a privileged connection: console, broker, secret store, Ironchip Connect and agent, and what each one does.

URL: https://docs.ironchip.com/en/pam/conceptos/arquitectura/

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](https://docs.ironchip.com/en/pam/boveda/rotacion/).
- **[Checkouts and break-glass](https://docs.ironchip.com/en/pam/boveda/checkouts/)**, to hand over a machine's password with a reason and a record, and rotate it when it is returned.
- **[Team passwords](https://docs.ironchip.com/en/pam/boveda/contrasenas/).** 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](https://docs.ironchip.com/en/pam/boveda/secretos/).** Compatible with the Vault API: your code and your continuous integration read their secrets from Ironchip without changing a line.
- **[Short-lived credentials](https://docs.ironchip.com/en/pam/boveda/credenciales-temporales/)** for AWS, Google Cloud, Azure and databases, created on request and removed automatically.

See [Credential vault](https://docs.ironchip.com/en/pam/conceptos/boveda/).

## More information

- [Just-in-Time sessions](https://docs.ironchip.com/en/pam/conceptos/sesiones-jit/)
- [Credential vault](https://docs.ironchip.com/en/pam/conceptos/boveda/)
- [Agent on the machines](https://docs.ironchip.com/en/pam/administracion/agente/)
- [Resources](https://docs.ironchip.com/en/pam/administracion/recursos/)