Akeyless Clients
An Akeyless Client is a unique identity, such as an application, user, or machine, which consumes secrets and/or authenticates itself through the Akeyless Platform. Registration and reception of the same uniquely identified client are counted as one client per month.
More about Akeyless Clients
An Akeyless client represents any identity authenticated to the Akeyless platform. Thus, a client can represent a “user,” that is, a human who logs into the service to consume policies or secrets. Every user who logs into the service while using authentication is considered a “client.” Similarly, every application, service, or any other machine-based system that authenticates to the Akeyless service is also considered a client.
There can be many different types of clients that authenticate and communicate with Akeyless Platform, using one of the below authentication methods:
For machine access, Akeyless supports:
- Cloud identity access management, such as AWS IAM, Azure AD, and GCP.
- Akeyless Universal Identity ™ for on-prem machines
- Kubernetes Auth
- Certificate-based Authentication
For human access, Akeyless supports
- LDAP
- SAML, OIDC , OAuth2.0/JWT, which are used by known identity providers such as Okta, Azure AD, and others.
Akeyless also supports the use of API Keys for authentication of both human and machine identities.
How do clients work in Akeyless?
When a client authenticates to the Akeyless Platform, whether that client is a user, application or server, it is associated with a unique entity within the Management Console and is reported to the identity system (IDP) via the different authentication methods listed above (Authentication List). Every client entity is created or verified during authorization.
How are Clients Counted?
The Akeyless Platform ensures that entities are not counted more than once. Upon authentication for the first time during a billing period, Akeyless creates a unique entity for each human, application, service, or CI/CD pipeline.
Consider, for instance, an application called App-A that needs a secret from Akeyless. Since App-A is associated with a specific entity via a unique identifier within Akeyless, Akeyless knows whenever Application-A authenticates and authorizes, and will not count App-A more than once.
What Unique Identifiers does Akeyless Use?
For human users, a unique identifier is usually an email, username, or UPN. Whenever a user logs in with a token, SAML, OIDC, OAuth2.0, JWT, or LDAP Identity Providers issue sub-claims containing details that uniquely identify the user. A sub-claim includes a key holding the unique identifier value configured for the user, and distinguishes between different users from within the same organization.
For machines, a unique identifier is usually an access ID. Whenever a machine logs in with that identifier it contains details that uniquely identify the machine, distinguishing between different machines from within the same organization.
For Kubernetes, a unique identifier will require Access_ID, Config and namespace.
Authentication methods and how they are reported
| Authentication Methods | Name reported by auth method |
|---|---|
| Machine Authentication | |
| AWS IAM | Access_ID |
| Azure AD | Access_ID |
| GCP | Access_ID |
| Akeyless Universal Identity™ | Token / Comment |
| Kubernetes Auth | Access_ID x Config x namespace |
| API Key | Access_ID |
| Certificate based Authentication | Unique Identifier – Common_Name, Organizational_Unit |
| Human Authentication | |
| LDAP/s | Unique Identifier – Username, Email Address, or UPN |
| SAML | Unique Identifier – Username, Email Address, or UPN |
| OIDC | Unique Identifier – Username, Email Address, or UPN |
| OAuth 2.0/JWT | Unique Identifier – Username, Email Address, or UPN |
| API Key | Access_ID |
