# Privileged access

> Just-in-Time privileged sessions with approval and recording, and an encrypted vault that rotates credentials and allows break-glass in emergencies.

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

Ironchip privileged access (PAM) lets administrators and external vendors reach servers, databases and Kubernetes clusters without a VPN, without shared accounts and without anyone knowing the password. This section serves whoever **administers** it (resources, policies, approvals, vault) and whoever **uses** it (requesting, connecting and checking out a password).

Product overview: [Ironchip privileged access (PAM)](https://www.ironchip.com/en/privileged-access).

## What changes compared with traditional access

- **No passwords to share.** Ironchip injects the credential at connection time and can change it when the session ends. The person never sees or types it.
- **No VPN and no inbound ports.** A connector inside your network opens an encrypted outbound tunnel to Ironchip: your servers are not published on the internet.
- **Privileges only when needed.** Every access is an approved window that closes automatically.
- **A stolen credential opens nothing.** Without the registered device, the safe zone and the access factors, an intercepted username and password are useless.
- **Every session is recorded**, including who requested it, who approved it, where they connected from and what they ran.
- **A vault that rotates on its own.** Privileged credentials are encrypted in a per-company store, Ironchip changes the ones it manages on a schedule and after every session, and in an emergency they are recovered with break-glass, with a reason and a record.

## How it works

1. The person **requests** access to a resource in the console, with a reason if the policy requires one.
2. If the policy requires approval, an approver receives the request with the access context and **approves** or rejects it, either once on request or on every connection.
3. The person **connects** with a single-use ticket, from the browser or with their usual client (SSH, RDP, `kubectl`, a database client).
4. The Ironchip PAM broker holds the connection while Ironchip checks the window, the address and the access factors, such as the device and the safe zone. Only then does it inject the credential and open the session.
5. The session is **recorded** from start to finish. When the window expires, access closes automatically.

For the detail of each piece, see [Architecture](https://docs.ironchip.com/en/pam/conceptos/arquitectura/).

## Supported resources

| Resource                                                 | How the person connects                    |
| -------------------------------------------------------- | ------------------------------------------ |
| [SSH](https://docs.ironchip.com/en/pam/recursos/ssh/)                             | Browser or `ssh` client                    |
| [RDP and VNC](https://docs.ironchip.com/en/pam/recursos/rdp/)                     | Browser or remote desktop client           |
| [Kubernetes](https://docs.ironchip.com/en/pam/recursos/kubernetes/)               | `kubectl`                                  |
| [PostgreSQL and MySQL](https://docs.ironchip.com/en/pam/recursos/bases-de-datos/) | `psql`, `mysql` or another database client |
| [Web applications](https://docs.ironchip.com/en/pam/recursos/web/)                | Browser                                    |

## Compared with traditional PAM

|                        | Traditional PAM                             | Ironchip PAM                                                                                        |
| ---------------------- | ------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Privileged credentials | Stored in a vault and shared by check-out   | Nobody sees them: the broker injects them at connection time and can rotate them after each session |
| Emergencies            | An emergency account in a sealed envelope   | Break-glass with a reason, a time limit and a record, and rotation when it is returned              |
| Privileges             | Permanent or by check-out                   | Just-in-Time: an approved window that closes automatically                                          |
| Remote access          | VPN and jump server                         | Browser or your own client with a single-use ticket                                                 |
| If the login is stolen | Access to the vault and everything it holds | Without the device, the safe zone and the access factors, it does not open                          |
| Network                | Published inbound ports or VPN              | Outbound only: Ironchip Connect opens the tunnel from the inside                                    |
| Deployment             | A months-long project                       | On top of the identity provider, directory and console you already use                              |

## Where to start

## Frequently asked questions

### How do I give an external vendor access without a VPN?

The vendor requests access to a specific machine, a manager approves it, and the vendor connects from the browser or with their own client during a time window. The session is recorded and access closes automatically when the window ends.

### Do I need to open firewall ports?

No. Ironchip Connect is installed inside each site and opens an encrypted outbound tunnel to Ironchip. Servers are not published on the internet.

### Can I watch or end a session live?

Yes. Terminal and desktop sessions are recorded in full, and you can watch them as they happen and end them instantly from **PAM > Sessions**. See [Sessions and recordings](https://docs.ironchip.com/en/pam/administracion/sesiones/).

### What does the Ironchip agent control?

On Linux it decides which `sudo` commands run; on Windows, which programs can be opened. It also rotates the passwords of the local accounts the broker uses and reports the processes of each session and the ways in that bypass Ironchip. It is optional: see [Agent on the machines](https://docs.ironchip.com/en/pam/administracion/agente/).

### Does Ironchip have a password vault?

Yes. Privileged credentials are stored encrypted in a per-company store and nobody sees them: the broker uses them when connecting. Ironchip rotates the ones it manages on a per-resource schedule and after every session. If someone needs a machine's password, they take it out with a checkout or, in an emergency, with a break-glass, and it is rotated when it is returned. The same store holds the team's shared passwords and your applications' secrets. See [Credential vault](https://docs.ironchip.com/en/pam/conceptos/boveda/).

### What happens if normal access fails and there is an emergency?

Members of the break-glass group can take out the password of any machine Ironchip manages without anyone's approval, for a limited time and by writing down the reason. It is recorded in **PAM > Checkouts** and the password is changed when it is returned or when the time runs out. See [Checkouts and break-glass](https://docs.ironchip.com/en/pam/boveda/checkouts/).