# Cluster Access Settings **Cluster Access Settings** ## Overview During EKS Cluster Provisioning, the different authentication modes in Amazon EKS allows users to manage cluster access according to their needs, whether they prefer simplicity with IAM-based controls or require more granular configurations. This flexibility helps balance ease of use with detailed access management, aligning access controls with specific security and operational requirements. **Did you know?** Amazon EKS Cluster Access Settings can be managed through various methods: - [UI](https://docs.rafay.co/clusters/eks/provisioning/#cluster-access-settings) - [CLI](https://docs.rafay.co/clusters/eks/declarative/infra_gitops_rctl_examples/) - [Terraform](https://registry.terraform.io/providers/RafaySystems/rafay/latest/docs/resources/eks_cluster) - [GitOps](https://docs.rafay.co/gitops/stages/system_sync/) - [API](https://docs.rafay.co/automation/api/apis/) ## Authentication Mode Selection and EKS Access Entry APIs The selected authentication mode determines whether EKS Access Entry APIs can be used, which require the mode to be set to either API or API & Config Map. Users must opt-in to use these APIs, which can be applied to existing clusters or configured during the creation of new ones. By default, **ConfigMap** is selected, but users can switch to other options: - **EKS API**: Uses the EKS API for authentication, simplifying access management by relying solely on AWS IAM, which makes it easier to manage access through IAM roles and policies. - **EKS API and ConfigMap**: Utilizes both the EKS API and a ConfigMap for authentication, combining IAM with Kubernetes ConfigMap. This provides flexibility, allowing for both IAM and manual role management within the cluster. - **ConfigMap**: Relies solely on a ConfigMap for authentication, offering full control over access through a Kubernetes ConfigMap. This mode requires manual updates to manage IAM role mappings. If the **Cluster Authentication Mode** is set to **ConfigMap**, users automatically receive **cluster administration access** and the option to configure this is not shown. For the other two modes, cluster administration access is always allowed. > **Note**: **Cluster administration access** can only be configured on Day 0, during the initial cluster setup. To add one or more users and provide access to a cluster or namespace, click **IAM Access Entry**. Here, users can add access entries along with access policies. **Permissions for Cluster Access Management** The following permissions are necessary to add, update, or delete cluster access entries: - "eks:ListAccessPolicies" - "eks:ListAccessEntries" - "eks:ListAssociatedAccessPolicies" - "eks:AssociateAccessPolicy" - "eks:CreateAccessEntry" - "eks:UpdateAccessEntry" - "eks:DescribeAccessEntry" - "eks:DisassociateAccessPolicy" - "eks:DeleteAccessEntry" - "iam:GetUser" The three different access levels are Cluster View, Cluster Edit, and Cluster Admin. These access entries can be assigned to individual users or groups. When a group is added, all members of that group can access the cluster or namespace as required. Define policies to allow access to the entire cluster or a specific namespace. **Important** When the **_Type_** is set to `Standard`, **_Username_**, **_kubernetes Groups_**, and **_Access Policies_** can be specified in the **IAM Access Entry configuration**. For all other types, specifying Username, kubernetes Groups and Access Policies is not permitted. Click **Save** and proceed with other configuration. **Important** When creating a new cluster, the `bootstrapClusterCreatorAdminPermissions` is set to 'true' by default, and users are not allowed to change it to 'false'. ## Migration Between Authentication Modes As a **Day-2 Operation**, users now have the flexibility to migrate between different authentication modes on an existing EKS cluster after the initial provisioning. This enhancement enables a smooth switch between authentication modes, allowing users to modify their authentication settings based on changing security policies and operational requirements without the need to fully re-provision the cluster. Additionally, users can easily revert any changes to a previous authentication mode whenever needed, providing further control and adaptability in managing cluster access. ### Migration via UI #### Step 1: Select Authentication Mode - On Day 2, select the required cluster from the cluster dashboard - Click on the settings gear icon and select **Migrate to Access Entry** - In the Migrate to Access Entry pop-up, the current authentication source is displayed along with two other available modes. The following example shows the current authentication mode as **_ConfigMap_** (default mode). Users can select either of the other two options: **_EKS API_** or **_EKS API and ConfigMap_** **Actions Triggered by Authentication Mode Selection** **EKS API** Selecting **EKS API** finalizes the migration, making it irreversible. All identity mappings will be deleted, and the **Migrate to Access Entry** option will be removed from the settings menu, preventing further migrations. If the user attempts to migrate via any interface, such as the UI, RCTL, or API, the system will throw an error stating that migration is not allowed. > ⚠️ **Note**: If the current source is **EKS API**, migration to access entry is not possible. **EKS API and ConfigMap** Selecting **EKS API and ConfigMap** migrates all identity mappings to access entries without deleting them from the **Identity Mappings** page. Once the migration is initiated, the provision status displays **Migrate to Access Entry In Progress**. Allow a few minutes for the migration process to complete. > ⚠️ **Note**: The status can be viewed in the AWS portal. #### Step 2: View Access Entries Configuration - Once the process is completed, click on the **Access tab** and view the current authentication mode from the **Access Configuration** tab - Make the necessary changes and click **Save Changes** To configure IAM access entries, navigate to the **IAM Access Entries** tab and click on **IAM Access Entry**. Then, provide the necessary details and click **Save** to complete the configuration. ### Migration via RCTL To migrate clusters to **Access Entry using RCTL**, run the following command to initiate the migration: ``` ./rctl migrate-to-access-entry --target-authentication-mode ``` Replace the placeholders: - ``: Name of the cluster to migrate. - ``: Target authentication mode (e.g., `API_AND_CONFIG_MAP` or `API`). ## Example Below is an example of the migration command: ``` ./rctl migrate-to-access-entry my-cluster --target-authentication-mode API_AND_CONFIG_MAP ``