Grant Permissions to Remote Storage

This document describes how to grant permissions to access remote storage for backup and restore. During the backup process, TiDB cluster data is backed up to the remote storage. During the restore process, the backup data is restored from the remote storage to the TiDB cluster.

AWS account permissions

Amazon Web Service (AWS) provides different methods to grant permissions for different types of Kubernetes clusters. This document describes the following three methods.

Grant permissions by AccessKey and SecretKey

The AWS client can read AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from the process environment variables to obtain the associated user or role permissions.

Create the s3-secret secret by running the following command. Use the AWS account’s AccessKey and SecretKey. The secret stores the credential used for accessing S3-compatible storage.

kubectl create secret generic s3-secret --from-literal=access_key=xxx --from-literal=secret_key=yyy --namespace=test1

Grant permissions by associating IAM with Pod

If you associate the user’s IAM role with the resources of the running Pods, the processes running in the Pods can have the permissions of the role. This method is provided by kube2iam.

Note

• When you use this method to grant permissions, you can create the kube2iam environment in the Kubernetes cluster and deploy TiDB Operator and the TiDB cluster.
• This method is not applicable to the hostNetwork mode. Make sure the value of spec.tikv.hostNetwork is set to false.

1. Create an IAM role.

   First, create an IAM User for your account.

   Then, Give the required permission to the IAM role you have created. Refer to Adding and Removing IAM Identity Permissions for details.

   Because the Backup CR needs to access the Amazon S3 storage, the IAM role is granted the AmazonS3FullAccess permission.

2. Associate IAM with the TiKV Pod:

   When you use BR to back up TiDB data, the TiKV Pod also needs to perform read and write operations on S3-compatible storage as the BR Pod does. Therefore, you need to add annotations to the TiKV Pod to associate it with the IAM role.

   kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"annotations":{"iam.amazonaws.com/role":"arn:aws:iam::123456789012:role/user"}}}}'

   After the TiKV Pod is restarted, check whether the Pod has the annotation.

Note

arn:aws:iam::123456789012:role/user is the IAM role created in Step 1.

Grant permissions by associating IAM with ServiceAccount

If you associate the user’s IAM role with serviceAccount of Kubernetes, the Pods using the serviceAccount can have the permissions of the role. This method is provided by EKS Pod Identity Webhook.

When you use this method to grant permissions, you can create the EKS cluster and deploy TiDB Operator and the TiDB cluster.

1. Enable the IAM role for the serviceAccount in the cluster:

   Refer to AWS documentation.

2. Create the IAM role:

   Create an IAM role and grant the AmazonS3FullAccess permissions to the role. Edit the role’s Trust relationships.

3. Associate IAM with the ServiceAccount resources.

   kubectl annotate sa tidb-backup-manager -n eks.amazonaws.com/role-arn=arn:aws:iam::123456789012:role/user --namespace=test1

4. Associate the ServiceAccount with the TiKV Pod:

   kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"serviceAccount": "tidb-backup-manager"}}}'

   Modify the value of spec.tikv.serviceAccount to tidb-backup-manager. After the TiKV Pod is restarted, check whether the Pod’s serviceAccountName is changed.

Note

arn:aws:iam::123456789012:role/user is the IAM role created in Step 2.

GCS account permissions

Grant permissions by the service account

Create the gcs-secret secret which stores the credential used to access GCS. The google-credentials.json file stores the service account key that you have downloaded from the GCP console. Refer to GCP documentation for details.

kubectl create secret generic gcs-secret --from-file=credentials=./google-credentials.json -n test1