Increase entity limits for agent ci_access and user_access to 500

Closes https://gitlab.com/gitlab-org/gitlab/-/issues/431133

app/services/clusters/agents/authorizations/ci_access/refresh_service.rb

@@ -7,7 +7,7 @@ module CiAccess
         class RefreshService
           include Gitlab::Utils::StrongMemoize
 
-          AUTHORIZED_ENTITY_LIMIT = 100
+          AUTHORIZED_ENTITY_LIMIT = 500
 
           delegate :project, to: :agent, private: true
           delegate :root_ancestor, to: :project, private: true

app/services/clusters/agents/authorizations/user_access/refresh_service.rb

@@ -7,7 +7,7 @@ module UserAccess
         class RefreshService
           include Gitlab::Utils::StrongMemoize
 
-          AUTHORIZED_ENTITY_LIMIT = 100
+          AUTHORIZED_ENTITY_LIMIT = 500
 
           delegate :project, to: :agent, private: true
           delegate :root_ancestor, to: :project, private: true

doc/user/clusters/agent/ci_cd_workflow.md

@@ -18,6 +18,7 @@ DETAILS:
 > - Support for Linux package installations was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5686) in GitLab 14.5.
 > - The ability to switch between certificate-based clusters and agents was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335089) in GitLab 14.9. The certificate-based cluster context is always called `gitlab-deploy`.
 > - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80508) from _CI/CD tunnel_ to _CI/CD workflow_ in GitLab 14.9.
+> - The [limit of agent connection sharing was raised](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149844) from 100 to 500 in GitLab 17.0
 
 You can use GitLab CI/CD to safely connect, deploy, and update your Kubernetes clusters.
 
@@ -80,7 +81,7 @@ To authorize the agent to access the GitLab project where you keep Kubernetes ma
 
    - Authorized projects must have the same root group or user namespace as the agent's configuration project.
    - You can install additional agents into the same cluster to accommodate additional hierarchies.
-   - You can authorize up to 100 projects.
+   - You can authorize up to 500 projects.
 
 All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection.
 The `kubeconfig` path is available in the environment variable `$KUBECONFIG`.
@@ -106,7 +107,7 @@ To authorize the agent to access all of the GitLab projects in a group or subgro
    - Authorized groups must have the same root group as the agent's configuration project.
    - You can install additional agents into the same cluster to accommodate additional hierarchies.
    - All of the subgroups of an authorized group also have access to the same agent (without being specified individually).
-   - You can authorize up to 100 groups.
+   - You can authorize up to 500 groups.
 
 All the projects that belong to the group and its subgroups are now authorized to access the agent.
 All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection.

doc/user/clusters/agent/user_access.md

@@ -14,6 +14,7 @@ DETAILS:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/390769) in GitLab 16.1, with [flags](../../../administration/feature_flags.md) named `environment_settings_to_graphql`, `kas_user_access`, `kas_user_access_project`, and `expose_authorized_cluster_agents`. This feature is in [Beta](../../../policy/experiment-beta-support.md#beta).
 > - Feature flag `environment_settings_to_graphql` [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124177) in GitLab 16.2.
 > - Feature flags `kas_user_access`, `kas_user_access_project`, and `expose_authorized_cluster_agents` [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125835) in GitLab 16.2.
+> - The [limit of agent connection sharing was raised](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149844) from 100 to 500 in GitLab 17.0
 
 As an administrator of Kubernetes clusters in an organization, you can grant Kubernetes access to members
 of a specific project or group.
@@ -39,8 +40,8 @@ To configure access:
 
 - In the agent configuration file, define a `user_access` keyword with the following parameters:
 
-  - `projects`: A list of projects whose members should have access.
-  - `groups`: A list of groups whose members should have access.
+  - `projects`: A list of projects whose members should have access. You can authorize up to 500 projects.
+  - `groups`: A list of groups whose members should have access. You can authorize up to 500 projects.
   - `access_as`: Required. For plain access, the value is `{ agent: {...} }`.
 
 After you configure access, requests are forwarded to the API server using