DOCS-424: Clarify ALLOWED_ACCESS_PERMISSIONS, add cache variables, and add SRA Docker Compose guidance

docs/Akeyless Gateway/configure-gateway/gateway-caching/cluster-cache-standalone.md

@@ -85,7 +85,7 @@ Use the following deployment-specific options to configure standalone cluster ca
 | Gateway Console | Not supported. Standalone cluster cache topology is deployment-level and is configured in infrastructure manifests. |
 | [Kubernetes (Helm)](https://docs.akeyless.io/docs/gateway-deploy-kubernetes-helm) | Set `globalConfig.clusterCache.enabled=true` in `values.yaml`. Configure persistence with `globalConfig.clusterCache.persistence.*` as needed, then [apply a Helm upgrade](https://helm.sh/docs/helm/helm_upgrade/). |
 | [Standalone Docker](https://docs.akeyless.io/docs/gateway-deploy-standalone-docker) | Not supported. Standalone cluster cache topology is not configured as a Docker-only deployment option. |
-| [Docker Compose](https://docs.akeyless.io/docs/gateway-deploy-docker-compose) | Not supported as a documented deployment mode for standalone cluster cache topology. |
+| [Docker Compose](https://docs.akeyless.io/docs/gateway-deploy-docker-compose) | Standalone cluster cache topology is not provisioned by Docker Compose. Docker Compose supports cache behavior tuning through Gateway environment variables (see [Cluster Cache Environment Variables (Docker Compose)](https://docs.akeyless.io/docs/cluster-cache-standalone#cluster-cache-environment-variables-docker-compose)). |
 | [Serverless AWS](https://docs.akeyless.io/docs/gateway-deploy-serverless-aws) and [Serverless Azure](https://docs.akeyless.io/docs/gateway-deploy-serverless-azure) | Not supported. Standalone cluster cache topology requires Kubernetes deployment resources. |
 
 Example (`values.yaml`):
@@ -117,3 +117,12 @@ For the full key reference, see [Helm Values Reference](https://docs.akeyless.io
 * `globalConfig.clusterCache.persistence.storageClass`: Sets the Kubernetes [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) for the PVC.
 * `globalConfig.clusterCache.persistence.size`: Sets the requested PVC size. See [Kubernetes Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory).
 * `globalConfig.clusterCache.extraArgs`: Passes Redis runtime arguments to the standalone cache container. For supported options, see [Redis configuration](https://redis.io/docs/latest/operate/oss_and_stack/management/config/) and [Redis persistence](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/).
+
+### Cluster Cache Environment Variables (Docker Compose)
+
+When deploying with [Docker Compose](https://docs.akeyless.io/docs/gateway-deploy-docker-compose), set these `gateway.env` variables to control how the Gateway uses Redis for caching (enablement and read preference). These settings tune runtime cache behavior only; they do not create, deploy, or manage standalone cluster cache topology resources.
+
+* `USE_CLUSTER_CACHE`: Set to `true` to enable the Redis-backed cluster cache for the curl proxy (proactive cache) layer. In a full Gateway deployment, set this together with `GATEWAY_CLUSTER_CACHE`; the SRA process uses `USE_CLUSTER_CACHE` alone.
+* `GATEWAY_CLUSTER_CACHE`: Set to `"enable"` to activate cluster cache mode for the Gateway configuration layer. Any non-empty value enables this; `"enable"` is the conventional value. If this variable remains set after the Redis instance is removed, the Gateway may fail to start until the container is recreated.
+* `REDIS_ADDR`: Address of the Redis instance, for example `akeyless-cache:6379`.
+* `PREFER_CLUSTER_CACHE_FIRST`: Controls read preference between the local in-memory cache and the Redis cache. For value behavior, see [Local Cache and Cluster Cache Read Preference](https://docs.akeyless.io/docs/cluster-cache-standalone#local-cache-and-cluster-cache-read-preference).

docs/Akeyless Gateway/configure-gateway/gateway-caching/proactive-caching.md

@@ -107,6 +107,7 @@ For the full key reference, see [Helm Values Reference](https://docs.akeyless.io
 * `PROACTIVE_CACHE_WORKERS`: Sets the number of concurrent fetch workers for the recommended implementation (requires `NEW_PROACTIVE_CACHE_ENABLE=true`). Default: `3`. Reduce to lower startup fan-out.
 * `PROACTIVE_CACHE_MINIMUM_FETCHING_TIME`: Sets the modified-secrets fetch interval in minutes for proactive caching. Default: `5`. Increase to reduce incremental cycle frequency. This value affects proactive refresh cadence in both the legacy and recommended implementations.
 * `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.
 
 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).
 

docs/Akeyless Gateway/deploy-gateway/gateway-deploy-docker-compose.md

@@ -116,6 +116,8 @@ ALLOWED_ACCESS_PERMISSIONS='[{"access_id":"<AccessID>","name":"<Allowed Method N
 
 To support local management of your Gateway configuration, you can set a list of `Access ID` values that can log in and manage your Gateway. This setting can also work with [Sub-Claims](https://docs.akeyless.io/docs/sub-claims) (when a shared authentication method is used), where for each entry you need to define a unique `name` which should describe the **Access Permission** object, with an `access-id`, `sub_claims` when applicable, and a list of `permissions`.
 
+For an explicit warning table comparing `ALLOWED_ACCESS_PERMISSIONS` and `GATEWAY_AUTHORIZED_ACCESS_ID`, see [Gateway Docker Advanced Configuration](https://docs.akeyless.io/docs/gateway-docker-advanced-configuration#warning-access-control-variable-comparison).
+
 Add the `ALLOWED_ACCESS_PERMISSIONS` environment variable to the `gateway.env` file, specifying a **JSON** list of allowed `Access IDs`:
 
 ```yaml gateway.env

docs/Akeyless Gateway/deploy-gateway/gateway-deploy-standalone-docker/gateway-docker-advanced-configuration.md

@@ -132,6 +132,10 @@ docker run -d -p 8000:8000  -p 5696:5696 -e ADMIN_ACCESS_ID="p-xxxxxxx" -v $PWD/
 
 To support local management of your Gateway configuration, you can set a list of `Access ID` values that can log in and manage your Gateway. This setting can also work with [Sub-Claims](https://docs.akeyless.io/docs/sub-claims) (when a shared authentication method is used), where for each entry you need to define a unique `name` which should describe the **Access Permission** object, with an `access-id`, `sub_claims` when applicable, and a list of `permissions`.
 
+> ℹ️ **Note:**
+>
+> Older deployments may use `ALLOWED_ACCESS_IDS`, which accepts a comma-separated list of access IDs but does not support per-entry permissions or sub-claims. `ALLOWED_ACCESS_PERMISSIONS` is the current variable and supersedes `ALLOWED_ACCESS_IDS`.
+
 For example:
 
 ```shell
@@ -147,7 +151,7 @@ Run the following:
 docker run -d -p 8000:8000 -p 5696:5696 -e GATEWAY_ACCESS_ID="p-xxxxxxx" -e ALLOWED_ACCESS_PERMISSIONS='[ {"name": "Administrators", "access_id": "p-yyyyyy", "sub_claims": {"email": ["test01@testhost.com", "test02@testhost.com"], "group": ["Devops"]}, "permissions": ["admin"]}]' --name akeyless-gw akeyless/base:latest-akeyless
 ```
 ```shell
-docker run -d -p 8000:8000 -p 8200:8200 -p 5696:5696 -e GATEWAY_ACCESS_ID="your-csp-access-id" -e GATEWAY_AUTHORIZED_ACCESS_ID='[ {"name": "access1", "access_id": "p-xxxxxxx", "sub_claims": {"username": ["username1", "username2"], "group": ["IT"]}, "permissions": ["admin"]},\n {"name": "access2", "access_id": "p-yyyyyy", "sub_claims": {"username": ["username1"], "group": ["rnd"]}, "permissions": ["targets", "defaults"]}, {"name": "access3", "access_id": "p-zzzzzzz", "sub_claims": {"email": ["xxx@example.com", "zzz@example.com"]}, "permissions": ["admin"]}]' --name akeyless-gw akeyless/base:latest-akeyless
+docker run -d -p 8000:8000 -p 8200:8200 -p 5696:5696 -e GATEWAY_ACCESS_ID="your-csp-access-id" -e ALLOWED_ACCESS_PERMISSIONS='[ {"name": "access1", "access_id": "p-xxxxxxx", "sub_claims": {"username": ["username1", "username2"], "group": ["IT"]}, "permissions": ["admin"]},\n {"name": "access2", "access_id": "p-yyyyyy", "sub_claims": {"username": ["username1"], "group": ["rnd"]}, "permissions": ["targets", "defaults"]}, {"name": "access3", "access_id": "p-zzzzzzz", "sub_claims": {"email": ["xxx@example.com", "zzz@example.com"]}, "permissions": ["admin"]}]' --name akeyless-gw akeyless/base:latest-akeyless
 ```
 
 In this case, the above creates an **Access Permission** object named **Administrators**, associated with an Auth Method `p-yyyyyy`, which is, for example, your [SAML](https://docs.akeyless.io/docs/auth-with-saml) or [OIDC](https://docs.akeyless.io/docs/auth-with-oidc) `Access ID`. A user that matches at least one [Sub-Claims](https://docs.akeyless.io/docs/sub-claims) attribute is authorized to access the Gateway with **Admin** permissions:
@@ -195,6 +199,35 @@ Full list of available permissions:
 
 You may also edit this parameter on your console, by going to the Gateways tab and selecting the desired Gateway. On the right of the screen, you will see the Gateway details, including **Access Permissions**.
 
+### Restrict Gateway Callers by Access ID
+
+Use `GATEWAY_AUTHORIZED_ACCESS_ID` to restrict which access IDs can call the Gateway API at all. This is a transport-layer allowlist enforced before any permission check: if the variable is set, the Gateway rejects requests from any access ID not on the list (the Gateway's own `GATEWAY_ACCESS_ID` is always implicitly allowed).
+
+#### Warning: Access Control Variable Comparison
+
+Use the table below to avoid mixing variables that serve different control planes:
+
+| Variable | Control plane | Purpose | Format | Legacy predecessor |
+| --- | --- | --- | --- | --- |
+| `ALLOWED_ACCESS_PERMISSIONS` | Gateway authorization (Gator access permissions) | Grants component-level permissions (for example, `admin`, `targets`, `log_forwarding`) to identities that can manage Gateway settings | JSON array of objects (`name`, `access_id`, optional `sub_claims`, `permissions`) | `ALLOWED_ACCESS_IDS` |
+| `GATEWAY_AUTHORIZED_ACCESS_ID` | Gateway ingress allowlist (transport layer) | Restricts which access IDs can call the Gateway API at all, before permission evaluation | Comma-separated list of access IDs | `RESTRICT_SERVICE_TO_ACCESS_IDS` |
+
+Set the value to a comma-separated list of access IDs:
+
+```shell
+docker run -d -p 8000:8000 -p 5696:5696 \
+  -e GATEWAY_ACCESS_ID="p-xxxxxxx" \
+  -e GATEWAY_ACCESS_KEY="matching-access-key" \
+  -e GATEWAY_AUTHORIZED_ACCESS_ID="p-aaaaaa,p-bbbbbb" \
+  --name akeyless-gw akeyless/base:latest-akeyless
+```
+
+> ℹ️ **Note:**
+>
+> `GATEWAY_AUTHORIZED_ACCESS_ID` replaces the legacy `RESTRICT_SERVICE_TO_ACCESS_IDS`. Both names are accepted, but `GATEWAY_AUTHORIZED_ACCESS_ID` is preferred for current deployments.
+
+`GATEWAY_AUTHORIZED_ACCESS_ID` and `ALLOWED_ACCESS_PERMISSIONS` serve different purposes and can be used together. `GATEWAY_AUTHORIZED_ACCESS_ID` controls **who can reach the Gateway**, while `ALLOWED_ACCESS_PERMISSIONS` controls **what those callers are permitted to do inside the Gateway**.
+
 ## Cluster Identity and Encryption
 
 ### Cluster Name & URL
@@ -355,9 +388,9 @@ The variables `MIN_TLS_VERSION=TLSv1.3` and `GODEBUG=tlsmlkem=1` enable hybrid P
 
 ### Cache Configuration
 
-Use these environment variables to enable runtime and proactive cache features for Docker deployments.
+Use the following environment variables to enable runtime and proactive cache features for Docker deployments.
 
-For behavior, topology semantics, and recommended proactive cache settings, see [Gateway Caching](https://docs.akeyless.io/docs/gateway-caching).
+For the full variable reference and behavior details, see [Runtime Caching](https://docs.akeyless.io/docs/runtime-caching), [Proactive Caching](https://docs.akeyless.io/docs/proactive-caching), and [Cluster Cache (Standalone)](https://docs.akeyless.io/docs/cluster-cache-standalone).
 
 ```shell
 docker run -d -p 8000:8000 -p 5696:5696 -e GATEWAY_ACCESS_ID="p-xxxxxxxxxxxx" -e GATEWAY_ACCESS_KEY="62Hu...xxx....qlg=" -e CACHE_ENABLE="true" -e PROACTIVE_CACHE_ENABLE="true" -e NEW_PROACTIVE_CACHE_ENABLE="true" -e CACHE_TTL="60" -e PROACTIVE_CACHE_MINIMUM_FETCHING_TIME="5" -e PROACTIVE_CACHE_WORKERS="3" --name akeyless-gw akeyless/base:latest-akeyless
@@ -366,8 +399,6 @@ docker run -d -p 8000:8000 -p 5696:5696 -e GATEWAY_ACCESS_ID="p-xxxxxxxxxxxx" -e
 docker run -d -p 8000:8000 -p 8200:8200 -p 5696:5696 -e GATEWAY_ACCESS_ID="your-access-id" -e GATEWAY_ACCESS_KEY="matching-access-key" -e CACHE_ENABLE="true" -e PROACTIVE_CACHE_ENABLE="true" -e NEW_PROACTIVE_CACHE_ENABLE="true" -e CACHE_TTL="number-of-minutes" -e PROACTIVE_CACHE_MINIMUM_FETCHING_TIME="number-of-minutes" -e PROACTIVE_CACHE_WORKERS="number-of-workers" --name akeyless-gw akeyless/base
 ```
 
-`PROACTIVE_CACHE_DUMP_INTERVAL` is still supported as the legacy secure backup interval for periodic cache backup, but the recommended proactive cache implementation is selected with `NEW_PROACTIVE_CACHE_ENABLE=true` and typically tuned with `PROACTIVE_CACHE_WORKERS` and `PROACTIVE_CACHE_MINIMUM_FETCHING_TIME` instead.
-
 It is also possible to configure runtime and proactive caching in the Gateway Console after the Gateway is deployed.
 
 ## Access Scope and Defaults

docs/Secure Remote Access/sra-setup/sra-docker/index.md

@@ -12,6 +12,10 @@ next:
 ---
 Use this page to deploy Akeyless Gateway with Secure Remote Access (SRA) components by using Docker Compose.
 
+> ℹ️ **Note:**
+>
+> The Docker Compose SRA deployment supports a subset of the configuration options available in Kubernetes. For production workloads or advanced configuration requirements, see [Remote Access on Kubernetes](https://docs.akeyless.io/docs/sra-setup-k8s).
+
 You can get the [configuration files](https://github.com/akeylesslabs/docker-compose/blob/main/README.md) that will be used to deploy the gateway with the SRA by cloning the following repository to your environment:
 
 ```shell

samples/unified-gateway/docker-compose-deploy/gateway.env

@@ -1,7 +1,7 @@
 # CLUSTER_NAME: The name of your Akeyless cluster (must match what's configured in Akeyless).
 # GATEWAY_ACCESS_ID / GATEWAY_ACCESS_KEY: Credentials obtained from the Akeyless console.
 # GATEWAY_ACCESS_TYPE: e.g., access_key/k8s/azure_ad/aws_iam/universal_identity/gcp/cert/ 
-# GATEWAY_AUTHORIZED_ACCESS_ID: Additional Access ID for delegated or extended usage.
+# GATEWAY_AUTHORIZED_ACCESS_ID: Comma-separated allowlist of access IDs permitted to call the Gateway API. If set, all callers not on the list (except the gateway admin) are rejected at the transport layer before any permission check.
 # VERSION: Which Gateway Docker image version/tag to pull (e.g. "latest").
 # ENABLE_METRICS: Set to "true" or "false" to enable metrics in the Gateway.
 # GATEWAY_CLUSTER_CACHE: Should remain "enable"