Container Service for Kubernetes:User management

User types

ACK One GitOps supports multi-user collaboration. The administrator can create users, delete users, and grant permissions to users. ACK One GitOps supports the following types of users:

• Local User

  Local users. The administrator can create local users and generate authentication tokens that are automatically used by the system to call the Argo CD API to create Argo CD applications and projects. If your team has a limited number of members, you can create local users. For more information about how to grant permissions to local users, see Grant permissions to a local user.

• Alibaba Cloud RAM user

  Alibaba Cloud Resource Access Management (RAM) users. You can use RAM users to log on to the Argo CD UI or Argo CD CLI. We recommend that you use RAM users to log on to the Argo CD UI or Argo CD CLI. By default, ACK One GitOps supports single sign-on (SSO) when you use RAM users to log on to the Argo CD UI or Argo CD CLI. For more information about how to grant permissions to RAM users, see Grant permissions to a RAM user.

Create a local user

Prerequisites

• The kubeconfig file of the Fleet instance is obtained in the ACK One console and a kubectl client is connected to the Fleet instance.

• GitOps is enabled for your ACK One Fleet instance. For more information, see Enable GitOps for the Fleet instance.

• The password of the Argo CD administrator is obtained and used to log on to the Argo CD CLI. For more information, see Access Argo CD by using the Argo CD CLI.

Procedure

Use the administrator account to create a local user on the Fleet instance. To create a local user, perform the following steps:

1. Run the following command to modify the argocd-cm ConfigMap of Argo CD:

   kubectl edit cm argocd-cm -n argocd

2. Add a local user named localuser1 to the argocd-cm ConfigMap.

   data:
     accounts.localuser1: login,apiKey    # Allow the local user to log on to the Argo CD UI and the Argo CD CLI, and generate an apiKey token. 
     accounts.localuser1.enabled: "true"  # Create local user localuser1.

3. Run the following command to query the local user:

   argocd account list

   Expected output:

   NAME        ENABLED  CAPABILITIES
   admin       true     login
   localuser1  true     login,apiKey   # The local user localuser1.

4. Run the following command to set a password and generate a token:

   # Set a password. 
   argocd account update-password \
     --account localuser1 \
     --current-password <admin password> \
     --new-password <localuser1-password>
   
   # Generate a token for localuser1. 
   argocd account generate-token --account localuser1
   eyJhb......

Configure Argo CD RBAC permissions

Argo CD allows you to configure Role-Based Access Control (RBAC) to limit SSO groups or local users from accessing Argo CD resources. To do this, define an RBAC role and map an SSO group or local user to the role.

Role introduction

To grant permissions to an SSO group or local user, you must first create a role and map the SSO group or local user to the role.

You can create custom roles or use the following predefined roles in Argo CD:

To define a permission policy, add one of the following settings to the .data.policy.csv field in the argocd-rbac-cm ConfigMap:

Argo CD supports the following resources: clusters, projects, applications, applicationsets, repositories, certificates, accounts, gpgkeys, logs, exec, and extensions.

Argo CD supports the following actions: get, create, update, delete, sync, override, and action/<api-group>/<Kind>/<action-name>.

The sync, override, and action/<api-group>/<Kind>/<action-name> actions take effect only on the applications resource.

Grant permissions to a local user

1. Run the following command to modify the argocd-rbac-cm ConfigMap of Argo CD:

   kubectl edit cm argocd-rbac-cm -n argocd

2. In the argocd-rbac-cm ConfigMap, grant permissions to a local user based on the following content:

   Important

   Do not modify other configurations in the ConfigMap.

   data:
     policy.csv: |
   ##  p, role:project-admin, applications, *, */*, allow
   ##  p, role:project-admin, projects, *, *, allow
       
       g, "14***01", role:admin          # Keep the current setting. 
       g, localuser1, role:admin         # Map localuser1 to role admin. 
   ##  g, localuser1, role:project-admin # Map localuser1 to role project-admin. 
     scopes: '[uid]'                     # Keep the current setting.

   The sample ConfigMap allows you to grant permissions in the following scenarios:

   • Map localuser1 to the predefined role admin. This way, localuser1 has full permissions on all Argo CD resources.

   • Map localuser1 to the custom role project-admin. This way, project-admin has full permissions on projects and applications. This setting is annotated in the sample ConfigMap.

Grant permissions to a RAM user

By default, ACK One GitOps supports SSO when you use RAM users to log on to the Argo CD UI or Argo CD CLI. After you use a RAM user to log on to the ACK One console, you can log on to the Argo CD UI or Argo CD CLI by using SSO without the need to enter the username and password again.

• If the RAM user is the administrator of the ACK One Fleet instance, ACK One GitOps automatically grants the RAM user administrator permissions on the Argo CD UI or Argo CD CLI.

• If the RAM user is not an administrator, the administrator of the Fleet instance needs to perform the following steps to grant permissions.

  1. Run the following command to modify the argocd-rbac-cm ConfigMap of Argo CD:

     kubectl edit cm argocd-rbac-cm -n argocd

  2. In the argocd-rbac-cm ConfigMap, refer to the permission policy in Grant permissions to a local user and grant permissions to the RAM user. In the following example, administrator permissions are granted to the RAM user:

     data:
       policy.csv: |
         g, "14***01", role:admin     # Do not change the configuration. 
         g, "27***02", role:admin     # Set the role of RAM User "27***02" to admin. 
       scopes: '[uid]'                # Keep the current setting.