Red Hat Security: Identity Management and Authentication
A secret is any piece of sensitive information that you want to make available only to a select group of people. Information used for authenticating to a system is a common type of secret, and can include PINs, certificates, passwords, and keys. The storage of secrets can be problematic and has given rise to items such as smart cards, however not all systems can support authentication using a smart card.
An IdM vault provides a place in IdM where you can store a secret. The secret is usually security-sensitive data, such as authentication credentials, that only a limited group of people or entities are authorized to access.
Vaults have the following characteristics:
A vault is only accessible to the vault owners, IdM users assigned as vault members by the vault owners, and the IdM administrator.
A user might not have permission to create a vault, but the IdM administrator can create one for that user and set them as its vault owner.
Users and services can access the vault from any machine enrolled in the IdM domain.
A vault contains only one secret, imported as a file. However, that file might contain data for multiple things that you want to keep secret, such as passwords, keytabs, or TLS certificates.
Vaults can contain private secrets for users, secrets for services, or secrets to be shared among several users. IdM supports these use cases with several types of vaults, providing options to specify whether the vault is owned by a user or service, and whether it is shared.
Vaults use the Key Recovery Authority (KRA) certificate system component as a back end for the storage of passwords and keys.
You can install the KRA system on the first IdM server by using the --setup-kra option of the ipa-server-install command.
You can also install the KRA system on an existing topology by assigning the role to an IdM server.
To do so, use the ipa-kra-install command on the target server:
[user@host ~]$ipa-kra-installDirectory Manager password:RedHat123^...output omitted... Done configuring KRA server (pki-tomcatd). Restarting the directory server The ipa-kra-install command was successful
Use the following command to determine how many KRA servers are running on the topology:
[user@host ~]$ipa server-role-find --role 'KRA server'--------------------- 1 server roles matched --------------------- Server name: idm.lab.example.com Role name:KRA serverRole status: enabled---------------------------- Number of entries returned 1 ----------------------------
Users can have different permissions on a vault:
- Owner
Vaults require at least one owner. Owners can be users or services, and can modify vault properties.
- Member
Vault members can access a vault created by an owner.
- Administrator
Vault administrators can manage all vaults.
Vaults can protect their contents with varying levels of encryption.
- Standard
The standard vault type allows the owner and members to retrieve secrets without providing a password.
- Symmetric
The symmetric vault type uses a symmetric key to protect secrets. The key must be provided when archiving and retrieving secrets.
- Asymmetric
The asymmetric vault type uses asymmetric key pairs to protect secrets. Secrets are archived using the public key and retrieved with the private key.
A vault container is a collection of vaults. IdM creates user or service vault containers dynamically when the first private vault for that user or service is created, and destroys it when the last private vault for that user or service is deleted.
- User container
Stores the vaults for a specific user.
- Service container
Stores the vaults for a specific service.
- Shared container
Stores vaults that can be shared between users or services.
Important
If an IdM administrator creates a user's first vault, the vault container and the vault are owned by that administrator and the user cannot access it. If this occurs, there are two ways to resolve the error:
Option 1: Add the user as a vault owner, then remove the administrator from the vault container and vault.
Option 2: Delete all vaults in the vault container, then delete the vault container by using the
ipa vaultcontainer-delcommand.
Common vault operations include adding a vault, storing (archiving) a secret, and retrieving a secret. The following examples show the creation and use of a personal standard vault:
[user@host ~]$kinit userPassword for user@LAB.EXAMPLE.COM:RedHat123^[user@host ~]$ipa vault-add payroll-vault \--type standard--------------------------- Added vault "payroll-vault" --------------------------- Vault name: payroll-vault Type: standard Owner users: user Vault user: user [user@host ~]$
Note
If you do not specify the vault type required to meet your needs when you create a vault, the type can be changed later with the ipa vault-mod command.
[user@host ~]$ipa vault-archive payroll-vault \--in ~/Documents/staff-salaries-2023.xlsx---------------------------------------- Archived data into vault "payroll-vault" ----------------------------------------
[user@host ~]$kinit userPassword for user@LAB.EXAMPLE.COM:RedHat123^[user@host ~]$ipa vault-retrieve payroll-vault \--out ~/Downloads/current.salaries.xlsx----------------------------------------- Retrieved data from vault "payroll-vault" -----------------------------------------
By default, a vault only allows 1 MiB uploads.
References
For more information, refer to the Vaults in IdM chapter of the Working with Vaults in Identity Management guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/working_with_vaults_in_identity_management/index#vaults-in-idm_working-with-vaults-in-identity-management
