PAM › User Guide
Adding Credentials
Store account passwords, private keys, and API keys securely in the GAccess vault for use with your servers and applications
Adding Credentials
Overview
A credential is a combination of an username and a secret, such as an account password, an SSH private key, or an API key,that GAccess stores securely in its vault. Once a credential is in the vault, it can be assigned to servers and applications so that GAccess connects on your behalf without ever exposing the secret to the people using it.
You add a credential from the Credentials section by clicking Add Credential.
Credential fields
| Field | Description |
|---|---|
| Credential Name | A unique, friendly name that identifies the credential in lists and when assigning it to targets (for example, Production DB Access). |
| Credential Type | The kind of secret this credential holds. See the table below. |
| Username | The account name the secret belongs to (for example, admin). For domain accounts, use the user@domain format. |
| Credential Value | The secret itself — the password, key, or token. It is masked as you type; use the eye icon to reveal what you have entered. |
| Description | Free-text notes about what the credential is for. Optional. |
| Tags | Labels that help you search and organize credentials. Type a tag and press Tab or Enter to add it. Optional. |
Credential types
| Type | Use it for |
|---|---|
| Local | A local account password on a single server (for example, a Linux, Windows local user, Network Device local account). |
| Domain | A directory account password (for example, an Active Directory user). Use the user@domain username format. |
| Private Key | An SSH private key for key-based login. You can upload a .pem file or paste the key text directly. |
| API Key | A token or API key used to authenticate to an application or service. |
| Application | A secret tied to an application login rather than a server or infrastructure account. |
.pem key file or paste the key contents. For all other types it is a single masked value field.Reconcile accounts
If your role permits it, you can choose a Credential Category at the top of the form:
- Standard — a regular account used to access target resources. This is the default.
- Reconcile Account — a privileged account that GAccess uses behind the scenes for password resets, verification, and account discovery, rather than for day-to-day connections.
Most credentials are Standard. Only create a Reconcile Account when an administrator has asked you to.
Assigning a credential to targets
A credential becomes useful once it is associated with a server or application. You don't link targets from the credential form itself — instead, you select the credential when adding a server or adding an application. See Adding Servers and Adding Applications.
Permissions
Access to each credential will use the ABAC concepct where it will be controlled by policies attached to that credential, by ownership, and by roles. From a credential's detail page you can add a policy that targets a user or a group and grants one or more of the following permissions:
| Permission | What it allows |
|---|---|
| Read | The credential is visible in the Credentials list with its metadata: name, type, username, and tags. The secret value is not revealed. |
| Connect | The credential can be used to open sessions to servers and applications. The Gateway uses the secret on the user's behalf; it is never displayed to them. |
| Manage | Full control. Reveal and download the secret, edit and delete the credential, and run verification and rotation (change/verify password). Grant further permissions. |
How permissions are determined
GAccess platform provides a granular Authorization control, combining the concepts of RBAC where authorization is granted by a role and ABAC where authorization is set per asset or atribute. To make it clearer the following list describes typical situations and how both models interacts:
- Creating a new credential requires the Create permission, which is granted through a Role, not through a per-credential policy.
- The owner — the person who created the credential — automatically has full (Manage) control of it.
- Permissions are additive: a user receives the combined total of every policy that applies to them, whether granted directly or through one of their groups, plus anything they get from ownership.
- Policies can be time-bound (a start and end date) and scheduled (specific days of the week and time ranges in a chosen timezone). Access applies only within those windows.