Remote storage access authorization

This article describes in detail how to authorize access to remote storage , For backup TiDB Cluster data to remote storage or restore backup data from remote storage to TiDB colony .

AWS Account Authorization

stay AWS In the cloud environment , Different types of Kubernetes Clusters provide different ways to grant permissions . This article introduces the following three permission granting configurations .

adopt AccessKey and SecretKey to grant authorization

AWS The client of supports reading  AWS_ACCESS_KEY_ID  as well as  AWS_SECRET_ACCESS_KEY  To obtain the permissions of the associated user or role .

establish  s3-secret secret, Use AWS Account number AccessKey and SecretKey To authorize . The secret Store for access S3 Compatible with stored credentials .

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

adopt IAM binding Pod to grant authorization

By putting the user's  IAM  Roles and running Pod Resource binding , send Pod The process running in gets the permissions owned by the role , This authorization method is made by  kube2iam  Provide .

Be careful

• When using this authorization mode , You can refer to  kube2iam file stay Kubernetes Create... In the cluster kube2iam Environmental Science , And deploy TiDB Operator as well as TiDB colony .
• This mode is not applicable to  hostNetwork  Network mode , Please ensure that the parameters  spec.tikv.hostNetwork  The value of is  false.

1. establish IAM role ：

   You can refer to  AWS Official documents To create a IAM role , And through  AWS Official documents by IAM Roles are given the required permissions . because  Backup  Need to access AWS Of S3 Storage , So here is IAM Given  AmazonS3FullAccess  Authority .

2. binding IAM To TiKV Pod：

   In the use of BR In the process of backup ,TiKV Pod and BR Pod The same needs to be true S3 Store for reading and writing , So here we need to give TiKV Pod In the play annotation To bind IAM role .

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

   wait until TiKV Pod After restart , see Pod Is this added annotation.

Be careful

arn:aws:iam::123456789012:role/user  For step 1 Created in the IAM role .

adopt IAM binding ServiceAccount to grant authorization

By putting the user's  IAM  Roles and Kubeneters Medium  serviceAccount  Resource binding , So that the ServiceAccount Account number Pod All have the permissions of this role , This authorization method is provided by  EKS Pod Identity Webhook  Services provide .

When using this authorization mode , You can refer to  AWS Official documents establish EKS colony , And deploy TiDB Operator as well as TiDB colony .

1. Enable... For the service account on the cluster IAM role ：

   You can refer to  AWS Official documents Open the EKS Clustered IAM Role authorization .

2. establish IAM role ：

   You can refer to  AWS Official documents Create a IAM role , Endow roles with  AmazonS3FullAccess  Authority , And edit the character  Trust relationships.

3. binding IAM To ServiceAccount Resources ：

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

4. take ServiceAccount Bound to the TiKV Pod：

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

   take  spec.tikv.serviceAccount  It is amended as follows tidb-backup-manager, wait until TiKV Pod After restart , see Pod Of  serviceAccountName  Is there any change .

Be careful

arn:aws:iam::123456789012:role/user  For step 2 Created in the IAM role .

GCS Account Authorization

Authorize through the service account key

establish  gcs-secret secret. The secret Store for access GCS Proof of .google-credentials.json  File storage users from GCP console Downloaded service account key. Specific operation reference  GCP Official documents .

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

Azure Account Authorization

stay Azure In the cloud environment , Different types of Kubernetes Clusters provide different ways to grant permissions . This article introduces the following two permission granting configurations .

Authorization by access key

Azure The client of supports reading  AZURE_STORAGE_ACCOUNT  as well as  AZURE_STORAGE_KEY  To obtain the permissions of the associated user or role .

establish  azblob-secret secret, Use Azure The access key of the account is authorized . The secret Store for access Azure Blob Storage Proof of .

kubectl create secret generic azblob-secret --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_STORAGE_KEY=yyy --namespace=test1

adopt Azure AD to grant authorization

Azure The client of supports reading  AZURE_STORAGE_ACCOUNT、AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET  To obtain the permissions of the associated user or role .

1. establish  azblob-secret-ad secret, Use Azure Account number AD To authorize . The secret Store for access Azure Blob Storage Proof of .

   kubectl create secret generic azblob-secret-ad --from-literal=AZURE_STORAGE_ACCOUNT=xxx --from-literal=AZURE_CLIENT_ID=yyy --from- literal=AZURE_TENANT_ID=zzz --from-literal=AZURE_CLIENT_SECRET=aaa --namespace=test1

2. binding secret To TiKV Pod:

   In the use of BR In the process of backup ,TiKV Pod and BR Pod The same needs to be true Azure Blob Storage Read and write , So here we need to give TiKV Pod binding secret.

   kubectl patch tc demo1 -n test1 --type merge -p '{"spec":{"tikv":{"envFrom":[{"secretRef":{"name":"azblob-secret-ad"}}]}}}'

   wait until TiKV Pod After restart , see Pod Whether these environment variables are added .