# Approvals

> Set who approves privileged access, how many people and when, and decide in the console the requests and sudo commands that are waiting for approval.

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

This page explains how approval of privileged access is configured and how requests and commands that are waiting for someone get decided. It is for whoever administers access and for whoever approves.

## Approval policies

An approval policy says who has to say yes, how many people and how long the window can last. It is added to an [access](https://docs.ironchip.com/en/pam/administracion/accesos/) as one more factor, alongside the device and the safe zone, and it also decides the `sudo` commands that a [control policy](https://docs.ironchip.com/en/pam/administracion/politicas/#control-policies) sends for approval.

### Create an approval policy

1. Go to **Authentication policies > Approval policies** and click **New policy**.

   [Image: Approval policies page with who approves, how many approvals and the longest window of each policy]

2. Enter **Name**, for example `Production`. This is what you choose when you configure an access's factors.
3. In **Who approves**, choose the approver group. With **Administrators (whoever holds the permission)**, anyone who has the **PAM approvals and sessions** permission with Update approves. It is usually better to name the system owners than the platform administrators.
4. In **Approvers required**, enter how many different people have to approve (from 0 to 10). With `0` it is self-service: the window opens when requested, and it is still recorded, limited and revocable.
5. In **When they are asked**, choose when:
   - **When access is requested**: it is approved once and a window opens.
   - **When the person connects**: nobody is asked until the person connects, and the connection is held while they decide.
6. In **Longest window (minutes)**, enter the maximum window length (`0` leaves it unlimited). If someone asks for more, it is shortened to this maximum.
7. Click **Create**.

The conditions are copied into each request when it is made: relaxing a policy does not let a half-approved request through, and tightening it does not affect windows that are already open. If an access has several approval policies, the strictest applies: more approvers, the shortest window, and approval on connection over approval on request.

An approval policy cannot be deleted while any access uses it.

## Deciding requests

**PAM > Approvals** shows what is waiting for a human decision. You see the requests you can decide: those from policies whose approver group includes you or, with the **PAM approvals and sessions** permission with Update, all of them.

[Image: Approvals page with pending access requests, the reason and the approvals each one has]

| Column        | What it shows                                                     |
| ------------- | ----------------------------------------------------------------- |
| **Who**       | Who is requesting access and how long ago.                        |
| **Wants**     | The machines and the integration through which they request them. |
| **Why**       | The reason they wrote.                                            |
| **Approvals** | How many approvals it has and how many it needs.                  |

1. Read the reason in **Why**.
2. Open **Options** and choose **Approve** or **Deny**. Confirm in the dialog that opens.

If several approvals are needed, each one is recorded and the window opens with the last one. The window starts counting at that moment and closes automatically.

Requests approved **on connection** appear when the person connects, with their connection held. What you approve is that specific connection: a new connection asks again. If nobody decides within 5 minutes, the connection is refused.

### Rules

- Nobody approves their own request or approves the same request twice. This cannot be configured otherwise.
- Approving does not skip any check: the device, safe zone and factors are checked on every connection.
- Every request, approval, denial and withdrawal is recorded.

## Commands waiting for approval

When a control policy rule says **Ask approvers**, the person waits at the `sudo` prompt and the command appears in **PAM > Approvals**, under **Commands waiting on a machine**, with who typed it, with which account, on which machine, the full command line, the rule that asked for approval and the time left.

[Image: The Commands waiting on a machine section with a sudo apk add held by a rule and the time left]

- The approvers of that rule's approval policy see **Approve** and **Refuse**.
- Whoever typed the command sees **Waiting for its approvers** and can withdraw it with **Take back**.
- If nobody decides within 5 minutes, or if the session ends first, the command is refused.
- Nobody approves their own command.

The decision appears in the session [recording](https://docs.ironchip.com/en/pam/conceptos/grabacion/), with who authorized it or why it was refused.

## More information

- [Approval](https://docs.ironchip.com/en/pam/conceptos/aprobacion/): the two moments of approval.
- [Request access](https://docs.ironchip.com/en/pam/usuarios/solicitar-acceso/): the request as seen by whoever makes it.