Credential Provider integrations overview
Aembit Credential Provider Integrations associate a third-party system (such as GitLab) with your Credential Providers to perform credential lifecycle management on your behalf. Credential Providers that use Credential Provider Integrations are responsible for maintaining an always-available credential value, which Aembit injects as part of an Access Policy.
Aembit's credential lifecycle management capabilities include creating, rotating, and deleting tokens.
List of Credential Provider Integrations​
How Credential Provider Integrations work​
In general, Credential Provider Integrations use the following process:
-
When you initially create Credential Provider, Aembit creates the third-party account or credential or both and securely stores it in Aembit's database.
-
Once 80% of the configured Credential Provider's Lifetime expires, Aembit rotates the third-party credential and securely stores the updated credential in Aembit's database.
-
When properly requested and authorized, Aembit provides the third-party credential from Aembit's database to the associated Agent Proxy.
If the injected credential fails, Agent Proxy continues to log the existing Workload Events to indicate the failure but doesn't generate a notification or take explicit action. For example, if you delete a credential on your third-party system, then the Workload fails until Aembit successfully rotates the credential.
-
When you delete a Credential Provider, Aembit deletes the third-party account and credential.
Deleting integrationsYou can't delete a Credential Provider Integration until you delete all its associated Credential Providers.
You can't change the association between a Credential Provider Integration and a Credential Provider after you create it.
How the GitLab Service Account integration works​
The GitLab Service Account integration uses your GitLab administrator account to connect with your GitLab instance and control credential lifecycle management for each Managed GitLab Account Credential Provider.
When creating a Managed GitLab Account Credential Provider, you scope it to only access specific GitLab Projects or GitLab Groups. Each provider creates an additional, separate GitLab service account that manages credentials on your behalf. This approach gives you fine-grained control over your GitLab workloads' credential lifecycle management.
GitLab subscriptions​
Depending on the type of GitLab plan you have, you have different choices of how to set up your GitLab Service Account integration.
- For GitLab.com plans, you must use
https://gitlab.com
when creating the integration. - For GitLab Dedicated or Self-Managed plans, you must use the URL of your GitLab dedicated or Self-Managed instance's.
See GitLab's plans for details about GitLab subscription types.
The distinction between the different GitLab plans requires you to use different API calls when creating the GitLab Service Account integration.
Process flow​
At a high level, the GitLab Service Account Credential Provider Integration works like this:
-
You initially connect Aembit to GitLab using your GitLab administrator account.
-
You create a Credential Provider with Managed GitLab Account integration.
-
Aembit creates a service account for each Credential Provider with your specified access scope.
-
Aembit securely stores credentials in its database.
-
Aembit automatically rotates credentials before expiration.
-
When requested and authorized, Aembit provides credentials to the Agent Proxy.