diff --git a/docs/AI Security/akeyless-ai-insight.md b/docs/AI Security/akeyless-ai-insight.md index 4d6d8770e..df86290b6 100644 --- a/docs/AI Security/akeyless-ai-insight.md +++ b/docs/AI Security/akeyless-ai-insight.md @@ -188,9 +188,13 @@ To test AI Insights in the Akeyless Console, follow these steps: 2. Navigate to AI Insights. 3. Start a chat session 4. Ask a natural language question. +5. Open the chat list in the left panel to review previous chats. +6. Use **Search chats** to find a specific chat in your history. ![Illustration for: 2. Navigate to AI Insights. 3. Start a chat session 4. Ask a natural language question.](https://files.readme.io/9214bc7c65691ab90764917b7da86d69a6be792b3c494b6289b338aabf90f851-chatInteraction.png) +AI Insights stores chat sessions per gateway selection so you can return to prior conversations and search them by title. + ## Troubleshooting | Issue | Resolution | diff --git a/docs/AI Security/identity-and-secrets-intelligence.md b/docs/AI Security/identity-and-secrets-intelligence.md index 5b66325a0..421de15f3 100644 --- a/docs/AI Security/identity-and-secrets-intelligence.md +++ b/docs/AI Security/identity-and-secrets-intelligence.md @@ -41,7 +41,10 @@ The current Inventory implementation exposes finding details for secret, identit The current Scanner implementation supports creating scanners, starting scans, stopping active scans, reviewing scan history, and navigating from a running scan directly to **Inventory**. -Current early-access scanner coverage includes GCP Scanner support and AWS Scanner support for cloud identities. +Current early-access scanner coverage includes: + +* **GCP Scanner** support, including enrichment of secret findings with last-access timestamps from Cloud Audit Logs (when those logs are available in the scanned environment) and identity resolution for group-member identities. +* **AWS Scanner** support for cloud identities, including scanner operation by way of AWS targets that use **Gateway Cloud Identity**. ## Operational Views diff --git a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-kubernetes/dedicated-k8s-auth-service-accounts.md b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-kubernetes/dedicated-k8s-auth-service-accounts.md index ae4a3ef3c..57bc81e97 100644 --- a/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-kubernetes/dedicated-k8s-auth-service-accounts.md +++ b/docs/Accessing Akeyless/access-and-authentication-methods/auth-with-kubernetes/dedicated-k8s-auth-service-accounts.md @@ -216,6 +216,17 @@ Where: * `token-reviewer-jwt`: The ServiceAccount `JWT` used to access the `TokenReview` API (relevant only to `native_k8s` access type). +> ℹ️ **Note (Gateway 4.53.0+):** +> +> You can configure TokenReview rate limiting for Gateway Kubernetes authentication by setting Gateway runtime environment variables: +> +> * `K8S_TOKEN_REVIEW_QPS` +> * `K8S_TOKEN_REVIEW_BURST` +> +> If these variables are not set, Gateway uses the Kubernetes client-go defaults: `QPS=5` and `Burst=10`. +> +> Scope: This setting applies only to `native_k8s` TokenReview flows. Rancher TokenReview flows are not controlled by these variables. + * `k8s-ca-cert`: The certificate to use to validate the Kubernetes cluster. * `k8s-issuer`: Optional, the [Kubernetes JWT issuer name](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) (default is `kubernetes/serviceaccount`). diff --git a/docs/Accessing Akeyless/access-and-authentication-methods/index.md b/docs/Accessing Akeyless/access-and-authentication-methods/index.md index ead72cfe0..ddb20a709 100644 --- a/docs/Accessing Akeyless/access-and-authentication-methods/index.md +++ b/docs/Accessing Akeyless/access-and-authentication-methods/index.md @@ -62,7 +62,7 @@ The following optional features are available across Authentication Methods: * **Expiration Date:** Select an access expiration date. This parameter is optional. Leave it empty for access to continue without an expiration date. * **Allowed Client IPs:** Enter a comma-separated list of CIDR blocks from which the client can issue calls to the proxy. By "client," we mean cURL, SDKs, and so on. This parameter is optional. Leave it empty for unrestricted access. * **Allowed Trusted Gateway IPs:** Comma-separated CIDR blocks. If specified, the Gateway using this IP range will be trusted to forward the original client IP. If empty, the Gateway's IP address will be used. -* **Audit Log Sub-Claims:** Include the following sub-claims values in Audit Logs. +* **Audit Log Sub-Claims:** Include selected token sub-claims in Audit Logs (for example, `email`, `username`, or `uid_comment` for UID token flows). * **JWT TTL (in minutes):** The time span from authentication to JWT expiration. * **Allowed Client Type:** Select the allowed client types that will be authorized to use this authentication method. Multiple options can be selected. For example, `CLI`, `Web UI`, `Extension`, `Mobile`, `Gateway Admin`, or `SDK`. * **Delete Protection:** Enable this option to protect the authentication method from accidental deletion. diff --git a/docs/Accessing Akeyless/rbac/index.md b/docs/Accessing Akeyless/rbac/index.md index ad46722b2..df4fd7503 100644 --- a/docs/Accessing Akeyless/rbac/index.md +++ b/docs/Accessing Akeyless/rbac/index.md @@ -114,6 +114,8 @@ The existing permissions for Secure Remote Access are as follows: * Upload Files: For RDP only. Allows a user to upload local files to a remote Windows machine using a button on the top menu. More information [here](https://docs.akeyless.io/docs/sra-remote-desktop#download--upload-files). * Download Files: For RDP only. Allows a user to download files from a remote Windows machine to their local machine. More information [here](https://docs.akeyless.io/docs/sra-remote-desktop#download--upload-files). +From Gateway `4.53.0` and later, SRA users can request access from the portal and approvers can process the request through the Event Center. + ## Administrative Rules With Administrative Rules, you can choose whether users have access only to the resources they own (**Own**), access to items users have `list` permission for (**Scoped**), or access to all resources (**All**). @@ -138,6 +140,17 @@ The following **Administrative Rules** can be set: * `Usage Reports` +## Reverse RBAC Review Coverage + +Reverse RBAC can be used to review who has access to object types beyond Items and Targets, including Secure Remote Access and Agentic Runtime Authority paths. + +For command syntax and full parameter details, see the [CLI Reference - Access Roles reverse-rbac command](https://docs.akeyless.io/docs/cli-reference-access-roles#reverse-rbac). + +Use the CLI `reverse-rbac` command with: + +* `--type sra` for Secure Remote Access rules +* `--type ara` for Agentic Runtime Authority rules + ## Event Center Rules You can define which events users are allowed to view based on their account permissions. diff --git a/docs/Accessing Akeyless/rbac/sub-claims.md b/docs/Accessing Akeyless/rbac/sub-claims.md index f943b9757..34ed3e350 100644 --- a/docs/Accessing Akeyless/rbac/sub-claims.md +++ b/docs/Accessing Akeyless/rbac/sub-claims.md @@ -12,6 +12,8 @@ next: --- For some of the Auth Methods like JWT/OIDC, Kubernetes, SAML, and LDAP that contain sub-claims or attribute-based access control (ABAC), also known as policy-based access control, as part of the given signed token, you can restrict the authorizations of the associated role to these specific claims or attributes. 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. +For UID tokens, token comments are available as a sub-claim key named `uid_comment`. + The sub-claims definition is in the structure of a map that contains keys that represent the field name of the sub-claims, and each key can contain several values ​​so the sub-claim must contain one of those values. The keys and values are case-sensitive. For example, assume sub-claims are set to: diff --git a/docs/Advanced Functionality/account-settings/index.md b/docs/Advanced Functionality/account-settings/index.md index 3d572b809..64c5db089 100644 --- a/docs/Advanced Functionality/account-settings/index.md +++ b/docs/Advanced Functionality/account-settings/index.md @@ -70,7 +70,7 @@ To update the address information on the account, click on the pencil icons, upd #### Secret Versions -When enabled, this feature allows the user to choose the maximum number of versions of Static Secrets, Rotated Secrets, and Targets to keep in the account for a given item. To update it, click on the pencil icon, choose a number, and click the check mark to save. In addition, you can choose to **force** a new version on update when versions are enabled in the account. +When enabled, this account-level feature allows the user to choose the maximum number of versions of Static Secrets, Rotated Secrets, and Targets to keep in the account for a given item and review version history from the item details view. To update it, click on the pencil icon, choose a number, and click the check mark to save. In addition, you can choose to **force** a new version on update when versions are enabled in the account. #### Delete Protection diff --git a/docs/Advanced Functionality/akeyless-agent.md b/docs/Advanced Functionality/akeyless-agent.md index c26b3c30d..fc02f105b 100644 --- a/docs/Advanced Functionality/akeyless-agent.md +++ b/docs/Advanced Functionality/akeyless-agent.md @@ -1,8 +1,11 @@ --- title: Akeyless Agent +excerpt: '' deprecated: false hidden: false metadata: + title: '' + description: '' robots: index --- The Akeyless [CLI](https://docs.akeyless.io/docs/cli#/) lets you set up an Agent that automatically delivers secrets from your Akeyless account and places them in specific locations on your system (**Linux** or **Windows** operating systems are supported). @@ -18,6 +21,7 @@ The supported items that can be fetched using the Agent are: * [Static Secrets](https://docs.akeyless.io/docs/static-secrets#/) * [Rotated Secrets](https://docs.akeyless.io/docs/rotated-secrets#/) +* [Dynamic Secrets](https://docs.akeyless.io/docs/dynamic-secrets) * [SSH Certificates](https://docs.akeyless.io/docs/sra-ssh-certificates#/) * [PKI Certificates](https://docs.akeyless.io/docs/certificate-lifecycle-management#/) @@ -55,6 +59,10 @@ destination = "path_to/static.txt" source = "path_to/rotated.tmpl" destination = "path_to/rotated.txt" +[[template]] +source = "path_to/dynamic.tmpl" +destination = "path_to/dynamic.txt" + [[template]] source = "path_to/ssh_cert.tmpl" destination = "path_to/ssh_cert.txt" @@ -113,6 +121,15 @@ password={{ .Data.Password }} {{- end -}} ``` +### Dynamic Secret + +```shell +{{- with dynamicSecret "/my_dynamic_secret" -}} +username={{ .Data.user }} +password={{ .Data.password }} +{{- end -}} +``` + ### SSH Certificate ```shell ssh_cert.tmpl diff --git a/docs/Advanced Functionality/audit-logs/index.md b/docs/Advanced Functionality/audit-logs/index.md index 4cae62643..e9155d7c3 100644 --- a/docs/Advanced Functionality/audit-logs/index.md +++ b/docs/Advanced Functionality/audit-logs/index.md @@ -27,9 +27,7 @@ Akeyless log auditing is important for cybersecurity because it provides records When using the console, you can navigate to the **Audit Logs** tab to view logs in the following format: -![](https://files.readme.io/7ec054a7174c4de9426983fab4b975d5eeee76db3c232f68c249ee7beea90113-Screenshot_2026-06-11_at_12.21.37.png) - -
+![Audit Logs view in the Akeyless Console.](https://files.readme.io/7ec054a7174c4de9426983fab4b975d5eeee76db3c232f68c249ee7beea90113-Screenshot_2026-06-11_at_12.21.37.png) These logs show you the time of the described action, what it was, whether it was successful or unsuccessful (status codes in the four hundreds means error), the client performing it, what IP it was performed from, and additional parameter tags such as access type or product type. @@ -40,20 +38,26 @@ You can filter your logs based on any of these rubrics or tags inside the Akeyle Another way to view your logs is to forward them in their raw form to tools such as Splunk, Logz.io, and so on. The logs will show up as a line of text, from which you can read the following information: -| Log Line | Description | -| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `Timestamp` | The log will start with a timestamp string in the format of Date `T` Time Timezone. | -| `account_id` | Account ID. | -| `access_id` | Access ID. | -| `action` | The type of action performed, for example, list items, create item, get item, and so on. A list of common log items can be found [here](https://docs.akeyless.io/docs/log-actions) | -| `item_type` | If the action was item specific, like create item, the item type will be listed here. | -| `status` | Standard HTTP status code of the following types, Informational responses (100–199), Successful responses (200–299), Redirection messages (300–399), or Client error responses (400–499). | -| `remote_addr` | The IP address from which the action was performed. | -| `duration` | The duration of the action in milliseconds. | -| `request_parameters` | More details about the action, for example, the name and details of a dynamic secret if one was fetched. | -| `unique_id` | Identifier for the specific user ID under the account (mostly relevant for human-to-machine auth methods). | -| `access_type` | [Authentication Method](https://docs.akeyless.io/docs/access-and-authentication-methods) type from which the action was performed. | -| `product` | Which Akeyless product does this log concern. For example, this could be **Secrets Management**, **Secure Remote Access**, or **Password Management** etc. | +| Log Line | Description | +| --- | --- | +| `Timestamp` | The log starts with a timestamp string in Date `T` Time Timezone format. | +| `seq_num` | Per-account sequence number used to preserve event ordering in audit logs. | +| `account_id` | Account ID. | +| `access_id` | Access ID. | +| `component` | Service component that emitted the audit event (for example, `microservices/uam`). | +| `action` | Type of action performed, such as list items, create item, or get item. For common actions, see [Log Actions](https://docs.akeyless.io/docs/log-actions). | +| `item_type` | If the action is item-specific (for example, create item), the item type is listed. | +| `status` | Standard HTTP status code: informational (`100`-`199`), success (`200`-`299`), redirection (`300`-`399`), client error (`400`-`499`), or server error (`500`-`599`). | +| `remote_addr` | IP address from which the action was performed. | +| `duration` | Duration of the action in milliseconds. | +| `request_parameters` | Additional action details, such as dynamic secret details when a value is fetched. | +| `scope_params` | Optional scoped-access suffix appended to some logs for exact scope matching (for example, item, role, auth method, target, event forwarder, and client auth scopes). | +| `unique_id` | Identifier for the specific user under the account (mostly relevant for human-to-machine auth methods). | +| `client_sub_claims` | Sub-claims captured for the authenticated client when configured on the authentication method (for example, `email`, `username`, and `uid_comment` for UID token flows). | +| `access_type` | [Authentication Method](https://docs.akeyless.io/docs/access-and-authentication-methods) type used for the action. | +| `product` | Akeyless product associated with the log, such as **Secrets Management**, **Secure Remote Access**, or **Password Management**. | + +To enrich Audit Logs with additional token parameters, configure **Audit Log Sub-Claims** on the relevant authentication method. For UID tokens, `uid_comment` is available as a sub-claim key. ## Tutorial diff --git a/docs/Akeyless Gateway/configure-gateway/gateway-access-permissions-reference.md b/docs/Akeyless Gateway/configure-gateway/gateway-access-permissions-reference.md index f25a8a117..aaf3dcbae 100644 --- a/docs/Akeyless Gateway/configure-gateway/gateway-access-permissions-reference.md +++ b/docs/Akeyless Gateway/configure-gateway/gateway-access-permissions-reference.md @@ -57,6 +57,8 @@ Console behavior note: in the current custom permission multi-select UI, `admin` Administrative operations for Gateway allowed access management require `admin` permission. +Gateway visibility in the Console is permission-scoped. Users with Gateway access permissions can view the Gateway in the Console only when their role includes Gateway administrative scope (`scoped` or `all`). + For item-related operations (`targets`, `classic_keys`, `dynamic_secret`, `rotated_secret`, and `rotate_secret_value`), access is evaluated in two scopes: 1. Gateway allowed access permission for the relevant component. diff --git a/docs/Akeyless Gateway/configure-gateway/gateway-caching/index.md b/docs/Akeyless Gateway/configure-gateway/gateway-caching/index.md index 888e3609e..5c7458815 100644 --- a/docs/Akeyless Gateway/configure-gateway/gateway-caching/index.md +++ b/docs/Akeyless Gateway/configure-gateway/gateway-caching/index.md @@ -37,6 +37,8 @@ Use this starting decision flow: For planning guidance and tradeoffs, see [Gateway Best Practices: Caching strategy considerations](https://docs.akeyless.io/docs/gateway-best-practices#caching-strategy-considerations). +For proactive deployments, use the recommended implementation (`NEW_PROACTIVE_CACHE_ENABLE=true`) to get shared 429 backoff handling and leadership-cycle worker restart behavior. For details, see [Proactive Caching](https://docs.akeyless.io/docs/proactive-caching). + For Kubernetes proactive cache sizing guidance, see [Gateway Best Practices: Resource planning for Kubernetes proactive cache](https://docs.akeyless.io/docs/gateway-best-practices#resource-planning-for-kubernetes-proactive-cache). ## Configure in Gateway UI diff --git a/docs/Akeyless Gateway/configure-gateway/gateway-caching/proactive-caching.md b/docs/Akeyless Gateway/configure-gateway/gateway-caching/proactive-caching.md index 1ea573d02..87c70dd50 100644 --- a/docs/Akeyless Gateway/configure-gateway/gateway-caching/proactive-caching.md +++ b/docs/Akeyless Gateway/configure-gateway/gateway-caching/proactive-caching.md @@ -48,10 +48,14 @@ All `list-items` and `get-value` calls during warm-up are issued under this iden 429 responses can occur when startup warm-up fan-out exhausts the per-access-ID limit window. The recommended implementation handles this automatically with a shared backoff gate: -* Applies a shared backoff delay across all workers on 429. +* Applies a shared backoff delay across proactive workers and RBAC refresh calls on 429. * Honors `Retry-After` or `will be released in ` headers when available. * Retries up to `PROACTIVE_CACHE_WORKERS × 10` attempts before giving up on a cycle. +### Leadership-Loss Handling + +In the recommended implementation, proactive workers are tied to the current leadership lease. When leadership is lost, active workers stop gracefully, the current cycle drains, and the next leadership cycle starts with a fresh jobs queue to avoid stale backlog carryover. + To further reduce rate-limit risk: * Reduce `PROACTIVE_CACHE_WORKERS` to lower burst concurrency. @@ -115,6 +119,9 @@ For the full key reference, see [Helm Values Reference](https://docs.akeyless.io * `CACHE_TTL`: Influences cache time-to-live and full-fetch cadence. Default: `60`. * `PROACTIVE_CACHE_DUMP_INTERVAL`: Sets the periodic secure cache backup interval in minutes for the legacy implementation. This variable has no effect when `NEW_PROACTIVE_CACHE_ENABLE=true`. For most tuning decisions on the legacy implementation, prefer `PROACTIVE_CACHE_MINIMUM_FETCHING_TIME`; adjust `PROACTIVE_CACHE_DUMP_INTERVAL` only when you need to change backup cadence specifically. +> ℹ️ **Note:** +> If Gateway starts without reachable SaaS configuration and initializes cache behavior from environment values, it temporarily enables `NEW_PROACTIVE_CACHE_ENABLE=true` for startup continuity until SaaS configuration becomes reachable. + For Redis topology choices, see [Cluster Cache (Standalone)](https://docs.akeyless.io/docs/cluster-cache-standalone) and [Cluster Cache High Availability (HA)](https://docs.akeyless.io/docs/cluster-cache-ha). ## Migrating from Legacy Proactive Caching diff --git a/docs/Akeyless Gateway/configure-gateway/gateway-log-forwarding.md b/docs/Akeyless Gateway/configure-gateway/gateway-log-forwarding.md index 1d0299327..7f56d7a5e 100644 --- a/docs/Akeyless Gateway/configure-gateway/gateway-log-forwarding.md +++ b/docs/Akeyless Gateway/configure-gateway/gateway-log-forwarding.md @@ -247,6 +247,10 @@ input { 5. From the **Log Service** dropdown list, select `Standard Output`. +> ℹ️ **Note:** +> +> To emit structured logs to container standard output, set the log format to `JSON`. + ## Sumo Logic 1. Log in to the Akeyless Gateway and go to **Log Forwarding**. diff --git a/docs/Akeyless Gateway/gateway-best-practices.md b/docs/Akeyless Gateway/gateway-best-practices.md index 8ae147b62..e6fdbe66d 100644 --- a/docs/Akeyless Gateway/gateway-best-practices.md +++ b/docs/Akeyless Gateway/gateway-best-practices.md @@ -141,6 +141,7 @@ Caching is optional and should be enabled based on business continuity, performa * Consider enabling Gateway caching to improve resilience during temporary SaaS connectivity interruptions and to reduce latency for repeated reads. * Consider enabling proactive cache when read performance and reduced first-read latency are priorities. +* For proactive cache, prefer the recommended implementation (`NEW_PROACTIVE_CACHE_ENABLE=true`) to get shared `429` backoff handling and leadership-cycle worker restart behavior. * Consider cluster cache when running multiple Gateway instances that should share cache state. * Evaluate security and operational tradeoffs before enabling caching: * Operational benefits: improved continuity, lower read latency, and reduced repeated upstream calls. diff --git a/docs/Encryption & KMS/kmip-server/index.md b/docs/Encryption & KMS/kmip-server/index.md index a4caf1cfc..798b27eb2 100644 --- a/docs/Encryption & KMS/kmip-server/index.md +++ b/docs/Encryption & KMS/kmip-server/index.md @@ -67,6 +67,7 @@ Flags: * `hostname`: Hostname of this KMIP server. * `root`: Required path to store KMIP objects. +* `certificate-ttl`: Optional. Server certificate TTL in days. Values must be `90` days or longer. Gateway `4.53.0` and later supports TTL values longer than one year. * `expiration-event-in`: Optional. Number of days before expiration to notify. Repeat the flag to set multiple events, for example `--expiration-event-in 1 --expiration-event-in 5`. * `gateway-url[=http://localhost:8000]`: Akeyless Gateway URL. @@ -111,7 +112,7 @@ akeyless kmip-create-client \ Flags: * `name`: A unique name of the KMIP client. The name can include the path to the virtual folder where you want to create the new client, using slash `/` separators. If the folder does not exist, it will be created together with the client. -* `certificate-ttl`: Client certificate TTL in days. +* `certificate-ttl`: Client certificate TTL in days. Values must be `90` days or longer. * `expiration-event-in`: Optional. Number of days before expiration to notify. Repeat the flag to set multiple events, for example `--expiration-event-in 1 --expiration-event-in 5`. * `gateway-url[=http://localhost:8000]`: Akeyless Gateway URL (port `8000`). * `output-file-folder`: Folder path to save client certificate files locally (for example, `.` for current working dir). diff --git a/docs/Integrations & Plugins/cli-reference/cli-ref-auth/cli-reference-k8s-auth-method.md b/docs/Integrations & Plugins/cli-reference/cli-ref-auth/cli-reference-k8s-auth-method.md index de17b3c54..640d114dd 100644 --- a/docs/Integrations & Plugins/cli-reference/cli-ref-auth/cli-reference-k8s-auth-method.md +++ b/docs/Integrations & Plugins/cli-reference/cli-ref-auth/cli-reference-k8s-auth-method.md @@ -240,6 +240,19 @@ akeyless gateway-update-k8s-auth-config \ `--delete-protection`: Protection from accidental deletion of this object, [true/false] +### TokenReview Rate Limit Configuration (Gateway 4.53.0+) + +TokenReview rate limiting is configured on the Gateway runtime (not as `gateway-create-k8s-auth-config` or `gateway-update-k8s-auth-config` flags). + +Set these environment variables on the Gateway deployment: + +* `K8S_TOKEN_REVIEW_QPS`: TokenReview client QPS value +* `K8S_TOKEN_REVIEW_BURST`: TokenReview client burst value + +If not set, Gateway uses the Kubernetes client-go defaults: `QPS=5` and `Burst=10`. + +Scope: applies only to `native_k8s` TokenReview calls. Rancher TokenReview flows are not controlled by these variables. + ## `update` Update a new Authentication Method that can authenticate using Kubernetes diff --git a/docs/Integrations & Plugins/cli-reference/cli-reference-access-roles.md b/docs/Integrations & Plugins/cli-reference/cli-reference-access-roles.md index 141f57ff6..e5e0eaf43 100644 --- a/docs/Integrations & Plugins/cli-reference/cli-reference-access-roles.md +++ b/docs/Integrations & Plugins/cli-reference/cli-reference-access-roles.md @@ -70,7 +70,7 @@ akeyless create-role --name `--isi-access`: Allow this role to access **Identity & Secrets Intelligence**. Currently only `none`, `scoped`, and `all` values are supported. For details, see [Identity and Secrets Intelligence](https://docs.akeyless.io/docs/identity-and-secrets-intelligence). -`--reverse-rbac-access`: Allow this role to view Reverse RBAC. Supported values: '`own`', '`all`'. +`--reverse-rbac-access`: Allow this role to view Reverse RBAC. Supported values: '`scoped`', '`all`'. `description`: Description of the object @@ -212,7 +212,9 @@ akeyless reverse-rbac \ `-p, --path`: **Required**, Path to an object -`-t, --type`: **Required**, Type of object (`item`, `am`, `role`, `target`) +`-t, --type`: **Required**, Type of object (`item`, `am`, `role`, `target`, `sra`, `ara`) + +Use `--type sra` to review Secure Remote Access rule access, and `--type ara` to review Agentic Runtime Authority rule access. ## `set-role-rule` @@ -295,7 +297,7 @@ akeyless update-role -n \ `--isi-access`: Allow this role to access **Identity & Secrets Intelligence**. Currently only `none`, `scoped`, and `all` values are supported. For details, see [Identity and Secrets Intelligence](https://docs.akeyless.io/docs/identity-and-secrets-intelligence). -`--reverse-rbac-access`: Allow this role to view Reverse RBAC. Supported values: '`own`', '`all`'. +`--reverse-rbac-access`: Allow this role to view Reverse RBAC. Supported values: '`scoped`', '`all`'. `--description`: Description of the object diff --git a/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-connect.md b/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-connect.md index 83be70622..a8e038bef 100644 --- a/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-connect.md +++ b/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-connect.md @@ -62,6 +62,21 @@ akeyless connect [flags] `-C, --command`: Command to execute on the target (non-interactive mode). Example: `-C='ls -al'` +For MySQL targets, `-C` also supports pre-connect MySQL client flags using the `pre:` prefix. + +Supported pre-connect MySQL flags: + +* `--disable-auto-rehash` +* `-A` (short alias of `--disable-auto-rehash`) + +You can combine pre-connect flags and post-connect payload in one command: + +* `-C "pre:-A; post:SELECT NOW();"` + +You can also pass only the pre-connect flag and continue in interactive mode: + +* `-C "pre:--disable-auto-rehash"` + `--k8s-tunnel`: Create an SSH tunnel with a Kubernetes proxy on a specific local port (`1024`–`65535`). Overrides `--tunnel` and `--command` when set `-V, --ssh-version`: Print the local SSH client version and exit @@ -101,6 +116,26 @@ akeyless connect \ -g http://my-gw.example.com:8000 ``` +MySQL with an interactive pre-connect flag: + +```shell +akeyless connect \ + -t my-mysql.example.com:3306 \ + -n /dynamic-secrets/my-mysql \ + -g http://my-gw.example.com:8000 \ + -C "pre:--disable-auto-rehash" +``` + +MySQL with pre-connect and post-connect payload in a single command: + +```shell +akeyless connect \ + -t my-mysql.example.com:3306 \ + -n /dynamic-secrets/my-mysql \ + -g http://my-gw.example.com:8000 \ + -C "pre:-A; post:SELECT NOW();" +``` + Open a Kubernetes tunnel on local port 8443: ```shell diff --git a/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-sra.md b/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-sra.md index a070586ce..5245a0dc6 100644 --- a/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-sra.md +++ b/docs/Integrations & Plugins/cli-reference/cli-reference-gateway/cli-reference-sra.md @@ -419,13 +419,13 @@ For HTTP endpoint details that map to these commands, see: ## File Transfer Commands -The Akeyless CLI supports SRA file transfer with `file upload` and `file download` when using version 1.145 or later. +The Akeyless CLI supports SRA file transfer with `file upload` and `file download` when using version 1.146 or later. -These commands run on the client machine and invoke the local `scp`/`ssh` tooling to perform transfer over an SRA tunnel. +These commands run on the client machine and use SFTP over an SRA tunnel. -At runtime, the CLI resolves target and bastion connection parameters (from command flags or profile), requests short-lived access by way of the configured SSH certificate issuer, and then establishes the tunnel used by `scp` for upload/download. +At runtime, the CLI resolves target and bastion connection parameters (from command flags or profile), requests short-lived access by way of the configured SSH certificate issuer, and then establishes the tunnel used by SFTP for upload and download. -If local `scp`/`ssh` binaries are missing or not available in `PATH`, file transfer commands fail on the client before transfer starts. +The client must support SFTP; file transfer commands fail if SFTP capability is not available. ```shell Command group akeyless file upload diff --git a/docs/Integrations & Plugins/cli-reference/cli-reference-rotated-secrets.md b/docs/Integrations & Plugins/cli-reference/cli-reference-rotated-secrets.md index 5a89a7fc1..b962dddf3 100644 --- a/docs/Integrations & Plugins/cli-reference/cli-reference-rotated-secrets.md +++ b/docs/Integrations & Plugins/cli-reference/cli-reference-rotated-secrets.md @@ -66,6 +66,11 @@ Commands to create a Rotated Secret These flags are used by multiple `rotated-secret create` and `rotated-secret update` subcommands. +Permission behavior: + +* For credentials-based rotators (for example, `password` rotator flows using `use-user-creds` or `use-target-creds`), creating the rotated secret supports list-only permissions on the associated target. +* For `target` rotator flows, read and update permissions on the target are still required. + `--grace-rotation-timing[=after]`: Controls whether graceful rotation creates the replacement credential before or after the old credential is removed. Supported values are `before` and `after`. `--lock-during-sra-session`: Lock this rotated secret for read and update while a Secure Remote Access (SRA) session is active. diff --git a/docs/Integrations & Plugins/cli-reference/cli-reference-universal-secrets-connector.md b/docs/Integrations & Plugins/cli-reference/cli-reference-universal-secrets-connector.md index 97b12ed10..e0e7fe8dc 100644 --- a/docs/Integrations & Plugins/cli-reference/cli-reference-universal-secrets-connector.md +++ b/docs/Integrations & Plugins/cli-reference/cli-reference-universal-secrets-connector.md @@ -130,6 +130,72 @@ akeyless usc create \ `--selected-repositories`: Explicit list of GitHub repositories selected for this operation +## Folder Sync Commands + +Use these commands to sync entire folder contents through Universal Secrets Connector. + +### `folder sync` + +Sync folder secrets by creating or updating sync associations for items in a folder. + +#### Usage + +```shell +akeyless folder sync \ +--name \ +--usc-name +``` + +#### Flags + +`-n, --name`: **Required**, folder name + +`--usc-name`: Universal Secrets Connector name. If omitted, all attached USCs for the folder are processed. + +`--namespace`: Vault namespace (HashiCorp Vault targets) + +`--delete-remote`: Delete the remote secret as part of sync handling when relevant + +`-u, --gateway-url[=http://localhost:8000]`: API Gateway URL (Configuration Management port) + +### `folder sync-all` + +Trigger sync for all USC associations under a folder. + +#### Usage + +```shell +akeyless folder sync-all --name +``` + +#### Flags + +`-n, --name`: **Required**, folder name + +### `folder-delete-sync` + +Delete folder sync associations. + +#### Usage + +```shell +akeyless folder-delete-sync \ +--name \ +--usc-name +``` + +#### Flags + +`-n, --name`: **Required**, folder name + +`--usc-name`: **Required**, Universal Secrets Connector name + +`--remote-secret-name`: Optional remote secret name filter when multiple syncs exist under the same USC + +`--delete-from-usc[=false]`: Delete secrets from the remote USC target as well + +`-u, --gateway-url[=http://localhost:8000]`: API Gateway URL (Configuration Management port) + `--region`: Optional, create the secret in a specific region (GCP only). If omitted, the secret is created as a global secret. ### `delete` diff --git a/docs/Secrets Management/rotated-secrets/_order.yaml b/docs/Secrets Management/rotated-secrets/_order.yaml index a5e2b0508..6ef73c77d 100644 --- a/docs/Secrets Management/rotated-secrets/_order.yaml +++ b/docs/Secrets Management/rotated-secrets/_order.yaml @@ -3,6 +3,7 @@ - create-a-database-rotated-secret - create-a-docker-hub-rotated-secret - gcp-rotated-secret +- create-a-hashicorp-vault-rotated-secret - create-an-ldap-rotated-secret - linked-target-rotated-secret - openai-rotated-secret diff --git a/docs/Secrets Management/rotated-secrets/create-a-database-rotated-secret.md b/docs/Secrets Management/rotated-secrets/create-a-database-rotated-secret.md index c57c5b890..16977e3e6 100644 --- a/docs/Secrets Management/rotated-secrets/create-a-database-rotated-secret.md +++ b/docs/Secrets Management/rotated-secrets/create-a-database-rotated-secret.md @@ -109,6 +109,10 @@ You can find the complete list of parameters for this command in the [CLI Refere * **Rotator type:** Determines the rotator type: * **Password**: Rotates the password defined inside the Rotated Secret item. * **Target**: Rotates the password defined inside the [Database Target](https://docs.akeyless.io/docs/database-targets) item. + + > 👍 Note + > + > For credentials-based rotation flows (for example, **Password** rotator with either **User credentials** or **Target credentials**), creating the Rotated Secret supports list-only permissions on the associated target. * **Username:** Defines the DB username which password should be rotated. * **Password:** Defines the password to rotate. diff --git a/docs/Secrets Management/rotated-secrets/create-a-hashicorp-vault-rotated-secret.md b/docs/Secrets Management/rotated-secrets/create-a-hashicorp-vault-rotated-secret.md new file mode 100644 index 000000000..92e3c66a5 --- /dev/null +++ b/docs/Secrets Management/rotated-secrets/create-a-hashicorp-vault-rotated-secret.md @@ -0,0 +1,71 @@ +--- +title: HashiCorp Vault Rotated Secret +excerpt: '' +deprecated: false +hidden: false +metadata: + title: '' + description: '' + robots: index +next: + description: '' +--- +You can create a Rotated Secret for a HashiCorp Vault target when you want Akeyless to manage a rotated secret item stored in HashiCorp Vault. + +## Prerequisites + +* An [Akeyless Gateway](https://docs.akeyless.io/docs/gateway-overview). +* A [HashiCorp Vault Target](https://docs.akeyless.io/docs/hashicorp-vault-target) with permissions to create, delete, update, read, and list secrets. + +## Create a HashiCorp Vault Rotated Secret in the Console + +1. Log in to the Akeyless Console, and go to **Items > New > Rotated Secret > HashiCorp Vault**. + +2. Define a **Name** of the Rotated Secret, and specify the **Location** as a path to the virtual folder where you want to create the new Rotated Secret, using slash `/` separators. If the folder does not exist, it will be created together with the Rotated Secret. + +3. Define the remaining settings as follows: + + * **Target:** Select an existing [HashiCorp Vault Target](https://docs.akeyless.io/docs/hashicorp-vault-target). + + * **Gateway:** Select the desired corresponding Gateway. + + * **Description:** Optional, enter a description of the Rotated Secret. + + * **Tags:** Optional. Select one or more tags for the Rotated Secret, or enter the name of a new tag to be added as part of the creation process. + + * **Protection Key:** Optional, select the key used to encrypt the secret value. + + * **Auto rotate:** Enable automatic rotation and define the rotation interval. + +4. Click **Finish**. + +## Create a HashiCorp Vault Rotated Secret with the CLI + +To create a HashiCorp Vault Rotated Secret using the Akeyless CLI, run the following command: + +```shell +akeyless rotated-secret create hashi-vault \ +--name \ +--gateway-url 'https://:8000' \ +--target-name \ +--auto-rotate \ +--rotation-interval <1-365> +``` + +Where: + +* `name`: A unique name of the Rotated Secret. The name can include the path to the virtual folder where you want to create the new Rotated Secret, using slash `/` separators. If the folder does not exist, it will be created together with the Rotated Secret. + +* `gateway-url`: Akeyless Gateway URL (port `8000`). + +* `target-name`: The name of the [HashiCorp Vault Target](https://docs.akeyless.io/docs/hashicorp-vault-target) with which the Rotated Secret should be associated. + +* `auto-rotate`: Enable auto-rotation if you need to update the secret regularly. + +* `rotation-interval`: The number of days to wait between every automatic rotation (1-365). + +The HashiCorp Vault variant also supports the shared rotated-secret settings for protection keys, max versions, tags, and description. For the full parameter list, see the [CLI Reference - Rotated Secrets](https://docs.akeyless.io/docs/cli-reference-rotated-secrets#synchronization) section. + +## Working With Version History + +If secret versioning is enabled for the account, you can review the available versions for the rotated secret from the item details view. diff --git a/docs/Secrets Management/rotated-secrets/index.md b/docs/Secrets Management/rotated-secrets/index.md index 2c2166bfa..5ddf23e69 100644 --- a/docs/Secrets Management/rotated-secrets/index.md +++ b/docs/Secrets Management/rotated-secrets/index.md @@ -28,6 +28,7 @@ You can configure: * [Database Rotated Secret](https://docs.akeyless.io/docs/create-a-database-rotated-secret) * [Docker Hub Rotated Secret](https://docs.akeyless.io/docs/create-a-docker-hub-rotated-secret) * [GCP Rotated Secret](https://docs.akeyless.io/docs/gcp-rotated-secret) +* [HashiCorp Vault Rotated Secret](https://docs.akeyless.io/docs/create-a-hashicorp-vault-rotated-secret) * [LDAP Rotated Secret](https://docs.akeyless.io/docs/create-an-ldap-rotated-secret) * [Linked Target Rotated Secret](https://docs.akeyless.io/docs/linked-target-rotated-secret) * [Splunk Rotated Secret](https://docs.akeyless.io/docs/splunk-rotated-secret) diff --git a/docs/Secure Remote Access/sra-admin-guides/sra-akeyless-connect.md b/docs/Secure Remote Access/sra-admin-guides/sra-akeyless-connect.md index d64117bdb..3e40478b9 100644 --- a/docs/Secure Remote Access/sra-admin-guides/sra-akeyless-connect.md +++ b/docs/Secure Remote Access/sra-admin-guides/sra-akeyless-connect.md @@ -215,6 +215,24 @@ akeyless connect -t :27017 -g -n ":3306 -g -n "" ``` +> ℹ️ **Note (CLI v1.146.0+):** +> +> The `connect` command supports MySQL interactive flags. For the current supported options, run `akeyless connect -h`. + +MySQL interactive flags are passed through the `-C` argument using the `pre:` prefix. + +Example with the long-form MySQL flag: + +```shell +akeyless connect -t :3306 -g -n "" -C "pre:--disable-auto-rehash" +``` + +Example with the short alias (`-A`) plus a post-connect SQL statement: + +```shell +akeyless connect -t :3306 -g -n "" -C "pre:-A; post:SELECT NOW();" +``` + ### Amazon EKS ```shell diff --git a/docs/Secure Remote Access/sra-user-guides/sra-akeyless-scp.md b/docs/Secure Remote Access/sra-user-guides/sra-akeyless-scp.md index bab1f07df..9597e2c82 100644 --- a/docs/Secure Remote Access/sra-user-guides/sra-akeyless-scp.md +++ b/docs/Secure Remote Access/sra-user-guides/sra-akeyless-scp.md @@ -16,6 +16,8 @@ For interactive SSH, database access, and generic tunnel workflows, use [Akeyles For current deployments, use `akeyless file upload` and `akeyless file download`, which are built into the Akeyless CLI. +These commands use SFTP as the transfer protocol, replacing legacy SCP-style transfer flows for improved reliability and transfer performance. + This page also includes legacy `akeyless-scp` guidance for existing automation that still depends on the script. ## CLI Path Selection @@ -32,11 +34,11 @@ Effective access is controlled by SRA permissions, issuer policy, and target con The `akeyless file` command enables secure file transfer to and from remote targets through the SRA bastion. It is built into the Akeyless CLI and supports both upload and download operations without requiring additional scripts. -These commands run on the client machine and invoke the local `scp`/`ssh` tooling to perform transfer over an SRA tunnel. +These commands run on the client machine and use SFTP over an SRA tunnel. -At runtime, the CLI resolves target and bastion connection parameters (from command flags or profile), requests short-lived access by way of the configured SSH certificate issuer, and then establishes the tunnel used by `scp` for upload/download. +At runtime, the CLI resolves target and bastion connection parameters (from command flags or profile), requests short-lived access by way of the configured SSH certificate issuer, and then establishes the tunnel used by SFTP for upload and download. -If local `scp`/`ssh` binaries are missing or not available in `PATH`, file transfer commands fail on the client before transfer starts. +The client must support SFTP; file transfer commands fail if SFTP capability is not available. > ℹ️ **Note:** > @@ -47,7 +49,7 @@ If local `scp`/`ssh` binaries are missing or not available in `PATH`, file trans * Akeyless [CLI](https://docs.akeyless.io/docs/cli) (latest version recommended; run `akeyless update` to upgrade). * An [SSH certificate issuer](https://docs.akeyless.io/docs/sra-ssh-certificates). * An [Akeyless Gateway](https://docs.akeyless.io/docs/gateway-overview) with Remote Access enabled. -* A local `ssh` and `scp` client (for example, OpenSSH). +* A local `ssh` client with SFTP support (for example, OpenSSH). * OpenSSH v7.3 or higher on target servers. * The appropriate SRA permission on your certificate issuer: * **Upload**: `sra_upload_files`. diff --git a/docs/Secure Remote Access/sra-user-guides/sra-portal.md b/docs/Secure Remote Access/sra-user-guides/sra-portal.md index d724a8ed6..fd2a8d510 100644 --- a/docs/Secure Remote Access/sra-user-guides/sra-portal.md +++ b/docs/Secure Remote Access/sra-user-guides/sra-portal.md @@ -18,10 +18,10 @@ All Akeyless-supported [resource types](https://docs.akeyless.io/docs/sra-resour Currently, the SRA Portal supports the following authentication methods: -- [SAML](https://docs.akeyless.io/docs/auth-with-saml) -- [OIDC](https://docs.akeyless.io/docs/auth-with-oidc) -- [Certificate](https://docs.akeyless.io/docs/auth-with-certificate) -- [LDAP](https://docs.akeyless.io/docs/auth-with-ldap) +* [SAML](https://docs.akeyless.io/docs/auth-with-saml) +* [OIDC](https://docs.akeyless.io/docs/auth-with-oidc) +* [Certificate](https://docs.akeyless.io/docs/auth-with-certificate) +* [LDAP](https://docs.akeyless.io/docs/auth-with-ldap) > ✅ **Tip (Allowed redirect URL):** If you are using SAML or OIDC auth methods, ensure your Gateway URL is trusted. @@ -47,9 +47,15 @@ Recommended discovery workflow: For approval-gated flows, see [Request Access and Approval Flow](https://docs.akeyless.io/docs/sra-request-access-and-approval-flow). -![](https://files.readme.io/11ba4ba151caf6160d6f57e98c41057fd75b7415113415cbce25daaf528c4b0c-Screenshot_2026-06-11_at_12.52.16.png) +![Secure Remote Access Portal resources view](https://files.readme.io/11ba4ba151caf6160d6f57e98c41057fd75b7415113415cbce25daaf528c4b0c-Screenshot_2026-06-11_at_12.52.16.png) -
+## Access Request Flow + +From Gateway `4.53.0` and later, the portal supports Secure Remote Access request flows, and approvers can process those requests through the Event Center. + +Use this flow to track request progress and quickly identify whether an SRA access request still requires approver action. + +For setup and permissions, see [Request Access](https://docs.akeyless.io/docs/request-access) and [RBAC](https://docs.akeyless.io/docs/rbac). ## Switch the Portal Theme @@ -75,9 +81,9 @@ In addition to existing hosts that are part of the allowed hosts on the [SSH Cer > ℹ️ **Note (Key Features):** > -> - **On-the-Fly Connections**: Users can provide a hostname or IP address for **RDP** or **SSH** sessions as needed. -> - **Temporary Host Addition**: Hostnames added through this feature are temporary and stored in the browser’s cache. -> - **Edit** and **Delete** Capability: Users can edit or remove the last added host from the list. +> * **On-the-Fly Connections**: Users can provide a hostname or IP address for **RDP** or **SSH** sessions as needed. +> * **Temporary Host Addition**: Hostnames added through this feature are temporary and stored in the browser’s cache. +> * **Edit** and **Delete** Capability: Users can edit or remove the last added host from the list. 1. In the SSH or RDP window, choose **Custom Target** and click the **+** button. 2. Select the **Permission Profile**. For example, [SSH Cert Issuer](https://docs.akeyless.io/docs/sra-ssh). diff --git a/docs/Universal Secret Connector/sync-secret/index.md b/docs/Universal Secret Connector/sync-secret/index.md index 8c57fa77c..2a3ef3e83 100644 --- a/docs/Universal Secret Connector/sync-secret/index.md +++ b/docs/Universal Secret Connector/sync-secret/index.md @@ -26,3 +26,25 @@ Sync workflows are available for both [Static Secrets](https://docs.akeyless.io/ ![Illustration for: An Authentication Method with Read and Update permission on the Rotated Secret item, and Read permission on the associated USC.](https://files.readme.io/84d68fd1c6e90bb12b48f538b74db51f35ad9c15a90235524268f07b20572d61-Synced_Secret-2.png) This solution makes managing secrets in remote endpoints more efficient and consistent, enabling a secure, centralized approach to secret lifecycle management. + +## Sync Entire Folder Contents + +You can sync all supported secrets under a folder in one operation. + +Use `folder sync` to create sync associations for folder contents, and `folder sync-all` to trigger sync for all folder associations: + +```shell +akeyless folder sync --name --usc-name +``` + +```shell +akeyless folder sync-all --name +``` + +Use `folder delete-sync` to remove folder-level associations: + +```shell +akeyless folder delete-sync --name --usc-name +``` + +For complete flags and behavior details, see [CLI Reference - Universal Secrets Connector](https://docs.akeyless.io/docs/cli-reference-universal-secrets-connector#folder-sync-commands). diff --git a/docs/Universal Secret Connector/universal-secrets-connector/hc-vault-universal-secrets-connector.md b/docs/Universal Secret Connector/universal-secrets-connector/hc-vault-universal-secrets-connector.md index 22e324e37..355f5b989 100644 --- a/docs/Universal Secret Connector/universal-secrets-connector/hc-vault-universal-secrets-connector.md +++ b/docs/Universal Secret Connector/universal-secrets-connector/hc-vault-universal-secrets-connector.md @@ -163,4 +163,32 @@ Once connected to a Target, you can access a Universal Secrets Connector in your More information and secret value can be viewed by selecting a specific secret, additionally, you will have the option to perform actions on the secret. +Additional capabilities include: + +* Account-level secret versioning applies across Akeyless item types such as Static Secrets, Rotated Secrets, and Targets, and is not specific to HashiCorp integrations. +* For USC-backed external secrets, the version details shown in the console can vary by provider and by the metadata and history returned by that provider. +* For larger HashiCorp Vault structures, you can sync the contents of an entire folder by using the folder sync commands. + +### Sync Entire Folder Contents + +For HashiCorp Vault USC flows in Multi-Vault Governance (MVG), use folder-level sync commands to apply sync associations across all supported secrets in a folder path. + +Common commands: + +```shell +akeyless folder sync --name --usc-name +``` + +```shell +akeyless folder sync-all --name +``` + +```shell +akeyless folder delete-sync --name --usc-name +``` + +For Vault-specific mapping, `folder sync` also supports `--namespace`. + +For full command flags and examples, see [CLI Reference - Universal Secrets Connector](https://docs.akeyless.io/docs/cli-reference-universal-secrets-connector#folder-sync-commands). + _Note:_ The **KV Secrets Engine v1** is not supported. Please use **KV Secrets Engine v2** when working with the Vault Universal Secrets Connector. diff --git a/docs/Universal Secret Connector/universal-secrets-connector/index.md b/docs/Universal Secret Connector/universal-secrets-connector/index.md index b5c73cd77..aa8f7e60d 100644 --- a/docs/Universal Secret Connector/universal-secrets-connector/index.md +++ b/docs/Universal Secret Connector/universal-secrets-connector/index.md @@ -17,7 +17,7 @@ When a user is granted `read` access to a **USC** item, they can act using the p Universal Secret Connector is also supported by the Akeyless [Kubernetes Injector](https://docs.akeyless.io/docs/akeyless-kubernetes-secrets-injector), allowing Kubernetes applications and workloads to access secrets and credentials sourced through USC securely. -After connecting to your Universal Secrets source, you can manage them from Akeyless, including viewing, adding, updating, deleting, and [syncing secrets](https://docs.akeyless.io/docs/sync-secret). The exact secret information that can be displayed in Akeyless varies between providers according to their unique attributes. +After connecting to your Universal Secrets source, you can manage them from Akeyless, including viewing, adding, updating, deleting, and [syncing secrets](https://docs.akeyless.io/docs/sync-secret). The exact secret information that can be displayed in Akeyless varies between providers according to their unique attributes. For HashiCorp Vault connectors, you can also review secret versions in the console and sync the contents of an entire folder to the connected USC. The **USC** solution operates in a governance loop model. It automatically detects and reflects changes to your secrets, whether those changes are made in Akeyless or in the remote secret management system. Akeyless does not store a copy of external secrets; therefore, data residency and security policies remain unchanged. The USC reflects updates in real time and does not require any configuration changes on the remote secret management endpoint.