diff --git a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-api-key.md b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-api-key.md index 32dca8fc6..6a37060a0 100644 --- a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-api-key.md +++ b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-api-key.md @@ -84,6 +84,39 @@ akeyless auth \ --access-key ``` +## Associate with Access Roles + +After creating the authentication method, associate it with one or more Access Roles so authenticated identities can perform actions in Akeyless. + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the API key authentication method. +3. Add the required Access Roles. +4. Save the changes. + +For role configuration details, see [Access Roles](https://docs.akeyless.io/docs/rbac). + +## Update an Existing API Key Authentication Method + +API key authentication methods can require updates over time, for example when rotating credentials or changing method-level settings. + +To update in the Console: + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the API key authentication method to update. +3. Update the required fields. +4. Save the changes. + +For CLI update flags, see [CLI Reference - Authentication](https://docs.akeyless.io/docs/cli-ref-auth#update). + +## Troubleshooting + +If API key authentication fails, check the following: + +* The **Access ID** and **Access Key** are from the same authentication method. +* The **Access Key** has not been rotated since the credential was stored. +* The authentication method is associated with the required Access Roles. +* The CLI profile is configured with the intended authentication method credentials. + ## Optional Features For optional features that apply across Authentication Methods, see [Common Optional Features](https://docs.akeyless.io/docs/access-and-authentication-methods#common-optional-features). diff --git a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-aws.md b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-aws.md index d3041b1d9..74a6ca1f6 100644 --- a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-aws.md +++ b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-aws.md @@ -87,6 +87,39 @@ akeyless auth \ > > AWS IAM authentication does not require privileged AWS permissions. Attach a minimally privileged IAM role to the resource that authenticates to Akeyless (for example, an EC2 instance, ECS task, or EKS pod). +## Associate with Access Roles + +After creating the authentication method, associate it with one or more Access Roles so authenticated identities can perform actions in Akeyless. + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the AWS IAM authentication method. +3. Add the required Access Roles. +4. Save the changes. + +For role configuration details, see [Access Roles](https://docs.akeyless.io/docs/rbac). + +## Update an Existing AWS IAM Authentication Method + +AWS IAM authentication methods can require updates over time, for example when bounded account IDs, ARNs, or related constraints change. + +To update in the Console: + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the AWS IAM authentication method to update. +3. Update the required fields. +4. Save the changes. + +To update with the CLI, use the relevant `akeyless auth-method update aws-iam` flags in [CLI Reference - Authentication](https://docs.akeyless.io/docs/cli-ref-auth#update). + +## Troubleshooting + +If AWS IAM authentication fails, check the following: + +* The workload is running with the expected IAM principal. +* The workload account matches configured bounded account IDs, ARNs, or other bounded fields. +* The configured **Access ID** and `aws_iam` access type are correct. +* For EC2-based flows, verify instance metadata service settings and hop limit requirements. + ## Optional Features For optional features that apply across Authentication Methods, see [Common Optional Features](https://docs.akeyless.io/docs/access-and-authentication-methods#common-optional-features). diff --git a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-azure.md b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-azure.md index 911172e99..549f69c95 100644 --- a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-azure.md +++ b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-azure.md @@ -96,6 +96,39 @@ akeyless auth \ For Azure US Government or Azure China, also set `--azure-cloud` to `AzureUSGovernment` or `AzureChinaCloud`. +## Associate with Access Roles + +After creating the authentication method, associate it with one or more Access Roles so authenticated identities can perform actions in Akeyless. + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the Azure AD authentication method. +3. Add the required Access Roles. +4. Save the changes. + +For role configuration details, see [Access Roles](https://docs.akeyless.io/docs/rbac). + +## Update an Existing Azure AD Authentication Method + +Azure AD authentication methods can require updates over time, for example when tenant boundaries, resource constraints, or custom issuer and key endpoints change. + +To update in the Console: + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the Azure AD authentication method to update. +3. Update the required fields. +4. Save the changes. + +To update with the CLI, use the relevant `akeyless auth-method update azure-ad` flags in [CLI Reference - Authentication](https://docs.akeyless.io/docs/cli-ref-auth#update). + +## Troubleshooting + +If Azure AD authentication fails, check the following: + +* The managed identity is enabled on the authenticating Azure resource. +* The tenant, subscription, and resource bounds match the authenticating identity context. +* Custom issuer, JWKS, and audience values are correct for the cloud environment. +* The authentication method is associated with the required Access Roles. + ## Optional Features For optional features that apply across Authentication Methods, see [Common Optional Features](https://docs.akeyless.io/docs/access-and-authentication-methods#common-optional-features). diff --git a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-email.md b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-email.md index ba761db89..d7b8af223 100644 --- a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-email.md +++ b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-email.md @@ -70,6 +70,39 @@ akeyless auth \ --admin-password ``` +## Associate with Access Roles + +After creating the authentication method, associate it with one or more Access Roles so authenticated users can perform actions in Akeyless. + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the email authentication method. +3. Add the required Access Roles. +4. Save the changes. + +For role configuration details, see [Access Roles](https://docs.akeyless.io/docs/rbac). + +## Update an Existing Email Authentication Method + +Email authentication methods can require updates over time, for example when changing the configured email address or other method settings. + +To update in the Console: + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the email authentication method to update. +3. Update the required fields. +4. Save the changes. + +To update with the CLI, use the relevant `akeyless auth-method update email` flags in [CLI Reference - Authentication](https://docs.akeyless.io/docs/cli-ref-auth#update). + +## Troubleshooting + +If email authentication fails, check the following: + +* The configured email address is correct. +* The password is valid and not expired. +* The authentication method is associated with the required Access Roles. +* If Two-Factor Authentication is enabled, the second-factor method is configured and accessible. + ## Optional Features For optional features that apply across Authentication Methods, see [Common Optional Features](https://docs.akeyless.io/docs/access-and-authentication-methods#common-optional-features). diff --git a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-gcp.md b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-gcp.md index 6ba38e121..2b6fa932d 100644 --- a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-gcp.md +++ b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-gcp.md @@ -134,6 +134,39 @@ akeyless auth \ For GitHub Actions-specific GCP Workload Identity Federation (WIF) workflows (including keyless OIDC and static service account JSON key examples), see [GitHub Actions Plugin](https://docs.akeyless.io/docs/github-action#gcp-workload-identity-federation). +## Associate with Access Roles + +After creating the authentication method, associate it with one or more Access Roles so authenticated identities can perform actions in Akeyless. + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the GCP authentication method. +3. Add the required Access Roles. +4. Save the changes. + +For role configuration details, see [Access Roles](https://docs.akeyless.io/docs/rbac). + +## Update an Existing GCP Authentication Method + +GCP authentication methods can require updates over time, for example when bounded projects, service account credentials, or audience values change. + +To update in the Console: + +1. In the Console, under **Administration**, navigate to **Users & Auth Methods**. +2. Select the GCP authentication method to update. +3. Update the required fields. +4. Save the changes. + +To update with the CLI, use the relevant `akeyless auth-method update gcp` flags in [CLI Reference - Authentication](https://docs.akeyless.io/docs/cli-ref-auth#update). + +## Troubleshooting + +If GCP authentication fails, check the following: + +* The configured `--gcp-audience` value matches the authentication method audience. +* The workload identity context matches configured bounded projects or service account constraints. +* Service account credential data is valid if credential-based validation is used. +* The authentication method is associated with the required Access Roles. + ## Optional Features For optional features that apply across Authentication Methods, see [Common Optional Features](https://docs.akeyless.io/docs/access-and-authentication-methods#common-optional-features). diff --git a/docs/Integrations & Plugins/cli-reference/cli-ref-auth/index.md b/docs/Integrations & Plugins/cli-reference/cli-ref-auth/index.md index f171cd1f1..92cfab3a5 100644 --- a/docs/Integrations & Plugins/cli-reference/cli-ref-auth/index.md +++ b/docs/Integrations & Plugins/cli-reference/cli-ref-auth/index.md @@ -888,6 +888,48 @@ akeyless auth-method update cert \ `-u, --unique-identifier`: **Required**, A unique identifier (ID) value should be configured for OIDC, OAuth2, LDAP and SAML authentication method types and is usually a value such as the email, username, or upn for example. Whenever a user logs in with a token, these authentication types issue a "sub-claim" that contains details uniquely identifying that user. This sub-claim includes a key containing the ID value that you configured, and is used to distinguish between different users from within the same organization. +#### `email` + +Update an existing Email Auth Method in the account + +##### Usage + +```shell +akeyless auth-method update email \ +--name \ +--new-name +``` + +#### Flags + +`--new-name`: Auth Method new name + +`-n, --name`: **Required**, Auth Method name + +`--descriptions`: Auth Method description + +`--access-expires[=0]`: Access expiration date in Unix timestamp (select 0 for access without expiry date) + +`--bound-ips`: A comma-separated CIDR block list to allow client access + +`--gw-bound-ips`: A comma-separated CIDR block list as a trusted Gateway entity + +`--force-sub-claims`: enforce role-association must include sub-claims + +`--jwt-ttl[=0]`: Credentials expiration time in minutes. If not set, use default according to account settings (see get-account-settings) + +`--product-type`: Choose the relevant product type for the Auth Method [`sm`, `sra`, `pm`, `dp`, `ca`] + +`--audit-logs-claims`: Additional sub-claims to include in Audit Logs. For example, `--audit-logs-claims email --audit-logs-claims username` + +`--expiration-event-in`: How many days before the Auth Method expires would you like to be notified. To specify multiple events, use the argument multiple times: `--expiration-event-in 1` `--expiration-event-in 5`, Relevant only when `access-expires` option is set. + +`--delete-protection`: Protection from accidental deletion of this object, [true/false] + +`--enable-mfa`: Enable MFA for this authentication method [true/false] + +`--mfa-type[=email]`: Enable two-factor authentication via [email/app] + #### `gcp` Update a new Auth Method that can authenticate using GCP IAM Service Account credentials or GCE instance credentials