Akeyless

B Akeyless Identity Security Platform (Secrets Management API)

Akeyless's OAuth2.0/JWT auth method trusts any JWKS URL you give it, with issuer, audience and sub-claim checks, so workloads never need a static Access Key to get in. Outbound runs from a Gateway you host: AWS, GCP and Azure targets can use that Gateway's cloud identity, but Okta, GitHub, Salesforce and most databases want a pasted token, private key or password.

Docs: docs.akeyless.io · Checked 2026-10-13 · source YAML · dispute via PR

Inbound A

How a workload running anywhere authenticates to this product.

OAuth2.0/JWT auth method validates tokens against any configured JWKS URL (or inline JWKS), with optional issuer and audience checks and per-role sub-claim matching that can be made mandatory (--force-sub-claims). Native AWS IAM, Azure AD, GCP, OCI, Kubernetes, certificate and Universal Identity methods cover platform identities; API Key (Access ID + Access Key) is the static fallback.

Issuers: any

docs.akeyless.io checked 2026-10-13
“jwks-uri: The URL to the JSON Web Key Set (JWKS) that contains the public keys that should be used to verify any JSON Web Token (JWT) issued by the authorization server.”
docs.akeyless.io checked 2026-10-13
“--force-sub-claims: enforce role-association must include sub-claims”
docs.akeyless.io checked 2026-10-13
“--audience: The audience in the JWT”
docs.akeyless.io checked 2026-10-13
“In other words, only clients whose tokens contain these sub-claims (in the case of JWT/OIDC) or attributes (in the case of SAML) will be allowed to access the rules defined in the role.”
docs.akeyless.io checked 2026-10-13
“The default usage relies on using the GitHub JWT (JSON Web Token) to authenticate to Akeyless.”
docs.akeyless.io checked 2026-10-13
“Cloud identities (CSP IAM)”

The JWT method is generic: any issuer that publishes a JWKS works, and the GitHub Actions plugin is documented as one instance of it (--jwks-uri https://token.actions.githubusercontent.com/.well-known/jwks with --force-sub-claims). Issuer and audience are optional fields, so trust is only as tight as the sub-claims you bind; without sub-claims any token signed by that JWKS gets in. Universal Identity covers on-prem hosts with a self-rotating token, though it still starts from an admin-issued token. The self-hosted Akeyless Gateway authenticates back to the SaaS with one of access_key, aws_iam, azure_ad, gcp, cert or uid (Helm gatewayAccessType), so a Gateway in a cloud can run with no static credential; the docs still lead with API key in several quickstarts. Akeyless itself labels API Key auth "not recommended for production use."

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Targets are used by the customer-hosted Gateway. AWS, GCP and Azure targets offer "Use Gateway's Cloud Identity" (the Gateway's own IAM role / service account / service principal, with optional AWS role assumption via External ID); Okta, GitHub, Salesforce, database and most other targets take a pasted API token, app private key, client secret or password.

docs.akeyless.io checked 2026-10-13
“The best practice for using IAM roles in AWS is to leverage them for granting temporary, least-privilege access to resources, rather than relying on long-term access keys for users. Use your Gateway cloud ID to use IAM roles.”
docs.akeyless.io checked 2026-10-13
“External ID: Optional, A unique auto-generated value used in your AWS account when configuring your AWS IAM role to securely delegate access to Akeyless”
docs.akeyless.io checked 2026-10-13
“Check the Use Gateway's Cloud Identity radio button to authenticate with the Gateway's Cloud IAM.”
docs.akeyless.io checked 2026-10-13
“Use Gateway's Cloud Identity is relevant for cases where your Gateway uses Azure service principal to authenticate against Akeyless.”
docs.akeyless.io checked 2026-10-13
“api-token: The Okta API token.”
docs.akeyless.io checked 2026-10-13
“github-app-private-key: The GitHub application private key.”
docs.akeyless.io checked 2026-10-13
“auth-flow: The type of the auth flow, either jwt or user-password.”
docs.akeyless.io checked 2026-10-13
“DB Password: Password of the database privilege user name.”

Checked AWS, GCP, Azure AD, Okta, GitHub, Salesforce and Database targets. Keyless: AWS, GCP and Azure via the Gateway's cloud identity, which is ambient identity of a Gateway the customer runs in their own cloud rather than a cross-tenant trust to Akeyless SaaS; it only works when the Gateway is hosted in that cloud. Static: Okta (API token), GitHub (private key of a customer-created GitHub App, not an Akeyless-owned app install), Salesforce (connected-app private key or client secret + password + security token), Azure AD explicit mode (client secret), GCP explicit mode (service account JSON key), AWS explicit mode (admin access key), databases (passwords; some DBs offer cloud identity). Akeyless mitigates the static ones by letting the target point at an Akeyless rotated secret, and AWS docs push rotation of explicit keys. Remaining targets (Kubernetes, SSH, LDAP, Splunk, OpenAI, Claude, Cloudflare, etc.) were not individually checked.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Every auth method, API Key included, can carry an access-expires date with expiry notifications, but it defaults to 0 (never). The account-level "Authentication Methods TTL" and jwt-ttl-max settings bound the session token issued after login, not the Access Key itself. No account policy forcing an Access Key expiry was found. docs.akeyless.io checked 2026-10-13 “--access-expires[=0]: Access expiration date in Unix timestamp (select 0 for access without expiry date)” docs.akeyless.io checked 2026-10-13 “Users can set the default length of time Authentication Methods in the account will last. At the maximum time set, the user will be logged out of Akeyless.”
✓ Rotation via API	Create (auth-method create api-key), reset and delete are all CLI/API operations. docs.akeyless.io checked 2026-10-13 “The Access Key is displayed only once. Store it securely. However, you can reset the access key at any time.” docs.akeyless.io checked 2026-10-13 “To reset the Access Key with the CLI, run the Akeyless reset-access-key command”
✓ Scoped keys	Each API Key is its own auth method bound to RBAC Access Roles and optional CIDR limits. docs.akeyless.io checked 2026-10-13 “After creating the authentication method, associate it with one or more Access Roles so authenticated identities can perform actions in Akeyless.” docs.akeyless.io checked 2026-10-13 “--bound-ips: A comma-separated CIDR block list to allow client access”
✓ Last-used visible	Judgment call. Akeyless can alert on auth methods unused for 90+ days, which is the purpose of this check, and the SDK's AuthMethod object carries an undocumented AccessDate field. No public doc page explicitly shows a "last used" timestamp for an Access Key. docs.akeyless.io checked 2026-10-13 “Set a global event for Auth methods that have not been used or changed within the usage interval, the minimum is 90 days.” raw.githubusercontent.com checked 2026-10-13 “AccessDate \| Pointer to [time.Time](time.Time.md) \| \| [optional]”
✗ Leak revocation	Akeyless does not appear anywhere on GitHub's supported patterns list, partner or user. docs.github.com checked 2026-10-13 “Partner alerts: Reported directly to secret providers that are part of secret scanning's partner program.”

Notes

Graded the SaaS secrets-management API that customers automate against. The same platform also covers Secure Remote Access, Password Manager and Certificate Lifecycle (auth-method --product-type sra/pm/ca), all on the same auth methods. Docs are public (docs.akeyless.io, with Markdown exports); nothing material was gated. Hygiene is graded against the API Key auth method, the only long-lived Akeyless-issued credential in the inbound path.

Badge

[![wif.tax grade](https://wif.tax/badge/akeyless-platform.svg)](https://wif.tax/p/akeyless-platform/)