# Credenciales temporales > Da a tus workloads credenciales de AWS, Google Cloud, Azure, PostgreSQL y MySQL que se crean al pedirlas y desaparecen solas al caducar. URL: https://docs.ironchip.com/pam/boveda/credenciales-temporales/ Esta página explica cómo conectar tus cuentas de nube y tus bases de datos para que tus workloads pidan credenciales de corta duración en lugar de usar claves permanentes. Es para quien administra la nube y los secretos de la compañía. ## Cómo funciona 1. Conectas una cuenta de AWS, Google Cloud o Azure con una credencial que puede crear otras. 2. Defines **roles**: qué credencial se crea (un usuario de IAM con ciertas políticas, un token de una cuenta de servicio, una cuenta de base de datos de solo lectura...) y cuánto dura. 3. Das el rol a un [workload](https://docs.ironchip.com/pam/boveda/secretos/). 4. El workload la pide con su cliente de Vault cuando la necesita. Ironchip la crea en ese momento y la borra cuando vence. Nadie guarda ni reparte claves permanentes: cada credencial existe solo mientras se usa. ## Antes de empezar - El permiso **PAM cloud accounts and credentials**. Para los roles de base de datos, también **PAM targets, sites and agents** con Read. - Para bases de datos: un recurso PostgreSQL o MySQL con la contraseña **Managed by Ironchip**. El almacén llega a la base de datos por la conexión con la que rota esa contraseña. Consulta [Rotación de contraseñas](https://docs.ironchip.com/pam/boveda/rotacion/). ## Conectar una cuenta de nube Ve a **PAM > Secrets > Credentials**. Las pestañas **AWS**, **Google Cloud** y **Azure** muestran un punto verde cuando están conectadas. [Imagen: Página Credentials con las pestañas de AWS, Google Cloud y Azure y la lista de roles] | Nube | Qué necesitas | Campos | | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | AWS | Un usuario de IAM que pueda crear usuarios de IAM y sus claves, y asumir los roles que nombren tus roles | **Access key**, **Secret key**, **Region** y, si hace falta, **IAM endpoint (optional)** y **STS endpoint (optional)** | | Google Cloud | Una cuenta de servicio que pueda crear cuentas de servicio y sus claves, fijar políticas de IAM y crear tokens de las cuentas que suplanten tus roles | Su clave JSON, con **Choose its key file** | | Azure | Una aplicación que pueda gestionar aplicaciones y entidades de servicio en Microsoft Graph y asignar roles en la suscripción | **Tenant (directory) id**, **Subscription id**, **Cloud**, **Application (client) id** y **Client secret** | Haz clic en **Connect**. Después, haz clic en **Change its key** (o **Change its client secret** en Azure): el almacén crea una credencial nueva y borra la que diste, de modo que a partir de ese momento solo el almacén la conoce. **Disconnect** olvida la cuenta. No se puede mientras haya roles de esa nube; las credenciales ya creadas siguen hasta que vencen. ## Añadir un rol 1. Haz clic en **Add role**. 2. En **Makes**, elige **AWS credentials**, **Google Cloud credentials**, **Azure credentials** o **Database accounts**. 3. Escribe **Name**. El workload lo pedirá como `/`, por ejemplo `aws/s3-reader` o `database/reporting`. 4. Completa lo de cada tipo: | Tipo | Opciones | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | AWS | **An IAM user, with policies**: ARN de políticas (**Policy ARNs**) o una política propia en JSON. **A role, assumed**: los ARN de los roles (**Role ARNs**). Duran 1 hora, renovable hasta 24. | | Google Cloud | **Tokens of an existing service account**, **Tokens of a service account made for it** o **Keys of a service account made for it**, con el proyecto, los permisos (**Bindings**) y, opcionalmente, los ámbitos. **Lasts**: de 15 minutos a 12 horas. | | Azure | **A service principal made for it, with roles** (una línea por rol y ámbito, y grupos opcionales) o **Client secrets of an existing application**. **Lasts**: de 15 minutos a 1 día. | | Base de datos | **Database**: el recurso. **Start from**: una plantilla (**PostgreSQL · read only**, **PostgreSQL · read and write**, **MySQL · read only**). **Statements that create the account, one per line**, con `{{name}}`, `{{password}}` y `{{expiration}}`. **Lasts**: de 15 minutos a 1 día. | 5. Haz clic en **Add role**. AWS, Google Cloud y Azure comprueban el rol al añadirlo y, si lo rechazan, la consola muestra su motivo. Un rol no se edita: para cambiarlo, crea otro y bórralo con **Remove role**. No se puede borrar mientras algún workload lo tenga. ## Dar el rol a un workload y pedir la credencial 1. En **PAM > Secrets > Workloads**, abre **Options > Edit workload** y marca el rol en **Short-lived credentials it asks for (optional)**. 2. Desde la aplicación, después de iniciar sesión como en [Secretos para aplicaciones](https://docs.ironchip.com/pam/boveda/secretos/#leer-un-secreto-desde-la-aplicaci%C3%B3n), pide la credencial: ```bash vault read aws/creds/s3-reader vault read gcp/impersonated-account/deployer/token # o gcp/roleset/deployer/token vault read azure/creds/reader vault read database/creds/reporting ``` La respuesta trae la credencial y su duración. El almacén la borra cuando vence o cuando se revoca el token del workload. ## Más información - [Secretos para aplicaciones](https://docs.ironchip.com/pam/boveda/secretos/) - [Bases de datos](https://docs.ironchip.com/pam/recursos/bases-de-datos/)