Resolver erros de permissão no Backup para GKE

Nesta página, descrevemos os erros de permissão que podem ocorrer ao usar o Backup para GKE, o que considerar ao realizar a ação e como resolver o erro.

Erro 100010101: falha ao fazer backup de PersistentVolumeClaim. Vinculação do IAM ausente para o projeto do locatário.

O erro 100010101 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido a uma vinculação ausente do gerenciamento de identidade e acesso para o projeto do locatário, resultando em uma mensagem de erro informando Failed to backup PersistentVolumeClaim - Missing IAM binding for tenant project.

O Backup para GKE cria snapshots do disco permanente do cluster do GKE. Os snapshots ficam no seu projeto Google Cloud , também conhecido como projeto de consumidor, e o Google Cloud os cria em um projeto de locatário que ele gerencia. O projeto do locatário existe na organização google.com, separada da sua.

O agente de serviço no projeto do locatário precisa de permissões específicas para usar a chave de criptografia gerenciada pelo cliente (CMEK) que criptografa o disco permanente referenciado pelo PersistentVolumeClaim do cluster. Essa permissão criptografa e descriptografa os dados do snapshot. Se o agente de serviço service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com não tiver a função roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK do disco, a operação de backup vai falhar.

Para resolver esse erro, siga estas instruções:

  1. Verifique se você tem permissões suficientes do IAM para modificar políticas do IAM na chave do Cloud Key Management Service no console Google Cloud , como roles/cloudkms.admin ou roles/owner.

  2. Localize o agente de serviço do Compute Engine do projeto do locatário usando o valor TENANT_PROJECT_NUMBER na mensagem status reason da operação de backup com falha. Por exemplo, service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com.

  3. Localize as seguintes informações da CMEK usadas para o disco permanente criptografado:

    • Nome da chave: o nome da sua chave de criptografia.

    • Keyring: o nome do keyring em que a chave está localizada.

    • Local: o Google Cloud local onde a chave está. Por exemplo, global ou us-central1.

  4. Para conceder ao agente de serviço do Compute Engine do projeto do locatário o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na sua CMEK, execute o comando gcloud kms keys add-iam-policy-binding usando a CLI do Google Cloud:

    gcloud kms keys add-iam-policy-binding KEY_NAME \
        --keyring KEY_RING \
        --location LOCATION \
        --member "serviceAccount:service-TENANT_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com" \
        --role roles/cloudkms.cryptoKeyEncrypterDecrypter
    

    Substitua:

    • KEY_NAME: o nome da chave de criptografia.

    • KEY_RING: o nome do keyring;

    • LOCATION: a Google Cloud localização da chave. Por exemplo, global ou us-central1.

    • TENANT_PROJECT_NUMBER: o número do projeto de locatário que você recebeu da mensagem status reason da sua operação de backup com falha.

    Se o comando for bem-sucedido, a saída será semelhante a esta:

    - members:
    - serviceAccount:service-987654321098@compute-system.iam.gserviceaccount.com
    role: roles/cloudkms.cryptoKeyEncrypterDecrypter
    
  5. Teste novamente a operação de backup. Se a operação ainda não for concluída, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010104: falha ao fazer backup de PersistentVolumeClaim: violação da restrição da política da organização ao criar o snapshot

O erro 100010104 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido a uma violação de restrição da política da organização durante a criação do snapshot, resultando em uma mensagem de erro informando Failed to backup PersistentVolumeClaim - Org policy constraint violation while creating snapshot.

O Backup para GKE cria snapshots do disco permanente do cluster do GKE. Os snapshots ficam no seu projeto Google Cloud , também conhecido como projeto de consumidor, e são criados em um projeto de locatário gerenciado por Google Cloud. O projeto do locatário existe na organização google.com, separada da sua.

A política da organização determina onde você pode criar recursos de armazenamento. O erro Constraint constraints/compute.storageResourceUseRestrictions violatedsignifica que um recurso ou snapshot está violando a política por ter sido criado em um projeto de locatário que não faz parte da estrutura organizacional permitida. Como o projeto do locatário está na organização do Google, ele fica fora da política definida, o que causa a falha do backup.

Para resolver esse erro, siga estas instruções:

  1. Localize a política da organização que implementa a restrição constraints/compute.storageResourceUseRestrictions. Para mais informações sobre como visualizar políticas da organização usando o console Google Cloud , consulte Como visualizar políticas da organização.

  2. Modifique a política constraints/compute.storageResourceUseRestrictions para incluir a pasta do projeto do locatário folders/77620796932 usada pelo Backup para GKE na lista de permissões.

  3. Salve as mudanças na política depois de adicionar a pasta à lista de permissões.

  4. Teste novamente a operação de backup depois que a política da organização for atualizada e propagada, o que geralmente leva alguns minutos. O backup precisa continuar sem violar as restrições de uso de recursos de armazenamento. Se a operação ainda não for concluída, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010106: falha ao fazer backup do PersistentVolumeClaim. Não há vinculação do IAM para o agente de serviço do Backup para GKE.

O erro 100010106 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido a uma vinculação do gerenciamento de identidade e acesso ausente para seu agente de serviço do Backup para GKE, resultando em uma mensagem de erro informando Failed to backup PVC - Missing IAM binding for Backup for GKE service agent.

O Backup para GKE exige permissões para usar a chave de criptografia gerenciada pelo cliente (CMEK) do BackupPlan para criptografar e descriptografar volumes de discos permanentes. Quando o agente de serviço do Backup para GKE não tem a função roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK BackupPlan, as operações de backup falham.

Para resolver esse erro, siga estas instruções:

  1. Identifique o agente de serviço gerenciado pelo Google do Backup para GKE específico do seu projeto. Por exemplo, service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com Para encontrar o número do projeto, use os seguintes métodos:

    • Use o painel de projetos do Google Cloud no console do Google Cloud .

    • Execute o comando gcloud projects describe usando a Google Cloud CLI:

      gcloud projects describe PROJECT_ID –format="value(projectNumber)"
      

      Substitua PROJECT_ID pelo nome exclusivo do projeto.

  2. Identifique os seguintes detalhes da CMEK:

    • Nome da chave: o nome da sua chave de criptografia.

    • Keyring: o nome do keyring em que a chave está localizada.

    • Local: o local Google Cloud onde a CMEK BackupPlan está localizada. Por exemplo, global ou us-central1.

  3. Para conceder ao agente de serviço do Backup para GKE o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na sua CMEK, use a CLI do Google Cloud para executar o comando gcloud kms keys add-iam-policy-binding:

    gcloud kms keys add-iam-policy-binding KEY_NAME \
        --keyring KEY_RING \
        --location LOCATION \
        --member "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com" \
        --role roles/cloudkms.cryptoKeyEncrypterDecrypter
    

    Substitua:

    • KEY_NAME: o nome da chave de criptografia.

    • KEY_RING: o nome do keyring;

    • LOCATION: a Google Cloud localização da chave. Por exemplo, global ou us-central1.

    • PROJECT_NUMBER: o número do projeto do Google Cloud .

  4. Verifique se você tem as permissões necessárias do Identity and Access Management na chave do Cloud Key Management Service. Por exemplo, roles/cloudkms.admin ou roles/owner.

  5. Verifique se você tem as permissões concedidas. Na saída do comando gcloud kms keys add-iam-policy-binding anterior, procure uma entrada semelhante a esta:

    -members:
    -serviceAccount:service-123456789012@gcp-sa-gkebackup.iam.gserviceaccount.com
    role: roles/cloudkms.cryptoKeyEncrypterDecrypter
    
  6. Teste novamente a operação de backup depois de conceder as permissões necessárias. Se a operação não for concluída, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010107: falha ao fazer backup de PersistentVolumeClaim. Vinculação do IAM ausente: conta de serviço do agente (KCP)

O erro 100010107 ocorre quando você tenta realizar uma operação de backup do Backup para GKE e o agente de serviço do cluster do Google Kubernetes Engine não tem acesso à sua chave de criptografia gerenciada pelo cliente (CMEK), resultando em uma mensagem informando Failed to backup PVC - Missing IAM binding - agent service account (KCP).

O agente de serviço do cluster do Google Kubernetes Engine, geralmente no formato service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com, é essencial para que o cluster do GKE interaja com os serviços Google Cloud. Quando seu plano de backup usa uma chave de criptografia gerenciada pelo cliente (CMEK). Esse agente de serviço precisa de permissões para criptografar e descriptografar seus dados de backup usando a CMEK. Se o plano de backup não tiver a função roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK, as operações de backup iniciadas no cluster vão falhar com um erro permission denied.

Para resolver esse erro, siga estas instruções:

  1. Verifique se você tem as permissões corretas para modificar as políticas do IAM na chave do Cloud Key Management Service. Por exemplo, cloudkms.admin ou roles/owner.

  2. Identifique o agente de serviço do cluster do Google Kubernetes Engine. Esse agente de serviço é criado e gerenciado automaticamente por Google Cloud para seus clusters do GKE. Por exemplo, service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com. Você precisa do número do projeto para criar a conta de serviço completa. Para encontrar o número do projeto, use um dos seguintes métodos:

    • Use o painel de projetos do Google Cloud no console do Google Cloud .

    • Execute o comando gcloud projects describe usando a Google Cloud CLI:

      gcloud projects describe PROJECT_ID –-format="value(projectNumber)"
      

      Substitua PROJECT_ID pela ID do seu projeto.

  3. Localize as seguintes informações da CMEK:

    • Nome da chave: o nome da sua chave de criptografia.

    • Keyring: o nome do keyring em que a chave está localizada.

    • Local: o Google Cloud local onde a chave está. Por exemplo, global ou us-central1.

  4. Conceda o papel roles/cloudkms.cryptoKeyEncrypterDecrypter no nível da CMEK. O agente de serviço do Google Kubernetes Engine precisa de permissões na sua chave de criptografia. Para conceder o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na sua CMEK, use a Google Cloud CLI para executar o comando gcloud kms key add-iam-policy-binding:

    gcloud kms keys add-iam-policy-binding KEY_NAME \
        --keyring KEY_RING \
        --location LOCATION \
        --member "serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
        --role roles/cloudkms.cryptoKeyEncrypterDecrypter
    

    Substitua:

    • KEY_NAME: o nome da chave de criptografia.

    • KEY_RING: o nome do keyring;

    • LOCATION: a Google Cloud localização da chave. Por exemplo, global ou us-central1.

    • PROJECT_NUMBER: o nome do projeto.

    O resultado será assim:

     - members:
     - serviceAccount:service-123456789012@container-engine-robot.iam.gserviceaccount.com
     role: roles/cloudkms.cryptoKeyEncrypterDecrypter
     ```
    
  5. Tente novamente a operação do Backup para GKE. Se a operação continuar falhando, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100020101: falha ao fazer backup do PersistentVolumeClaim. O PersistentVolumeClaim está vinculado a um tipo de PersistentVolume não compatível.

O erro 100020101 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha porque o PersistentVolumeClaim está vinculado a um tipo de PersistentVolume não compatível. O erro resulta na seguinte mensagem: PersistentVolumeClaims are bound to PersistentVolumes of unsupported types and cannot be backed up.

Esse erro ocorre quando a operação do Backup para GKE encontra um PersistentVolumeClaim vinculado a um PersistentVolume que usa um tipo de volume não compatível com o backup de dados do Backup para GKE. O Backup para GKE oferece suporte principalmente ao backup de dados de volumes do Persistent Disk. Se um PersistentVolumeClaim estiver vinculado a um PersistentVolume que não seja um disco permanente, a operação de backup vai falhar para os dados do PersistentVolumeClaim.

Para resolver esse erro, siga estas instruções:

  1. Liste todos os PersistentVolumeClaims e os PersistentVolumes vinculados a eles executando o comando kubectl get pvc. Revise esta lista para identificar os PersistentVolumes que são respaldados por tipos de volume sem suporte.

    kubectl get pvc --all-namespaces -o wide
    
  2. Determine o tipo de volume do PersistentVolume que é armazenado por um tipo de volume não compatível com o Backup para GKE executando o comando kubectl describe pv:

    kubectl describe pv PERSISTENT_VOLUME_NAME
    

    Substitua:

    PERSISTENT_VOLUME_NAME: o nome de PersistentVolume que tem um tipo de volume não compatível listado como coluna VOLUME na saída da etapa anterior.

    Na saída, use os campos Source e Driver para receber detalhes do provisionador de volume:

    • Para discos permanentes compatíveis: a saída será semelhante a Source.Driver: pd.csi.storage.gke.io ou Source.Type:GCEPersistentDisk.

    • Para tipos incompatíveis que estão causando o erro: a saída seria um driver de disco não permanente, por exemplo, Source.Driver:filestore.csi.storage.gke.io.

  3. Use um dos seguintes métodos para resolver o erro:

    • Migrar para um volume de disco permanente: recomendamos esse método para backups completos de dados. Se você precisar fazer backup dos dados reais do volume, use um disco permanente, o que envolve migrar seus dados do tipo de volume não compatível para um novo volume CSI de disco permanente. Para receber ajuda com a migração de um volume de disco permanente, entre em contato com o Cloud Customer Care.

    • Ative o modo permissivo no Backup para GKE: recomendamos esse método se o backup de dados não for necessário para volumes sem suporte. Se a migração de dados não for viável ou necessária (por exemplo, se o volume for apoiado por um serviço externo e você planeja reconectá-lo durante a operação de restauração), configure seu plano de backup do Backup para GKE para permitir que o backup prossiga no modo permissivo. Para mais informações sobre como ativar o modo permissivo, consulte Ativar o modo permissivo em um plano de backup.

  4. Tente novamente a operação do Backup para GKE. Com base no método escolhido para resolver o erro, a operação do Backup para GKE se comporta das seguintes maneiras:

    • Se você migrou para um volume de disco permanente, o backup será concluído para o volume, incluindo os dados dele.

    • Se você ativou o modo permissivo, a operação de backup vai ser concluída, mas os dados de volumes não compatíveis não serão incluídos no backup.

Se a operação continuar falhando, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100020104: falha ao fazer backup do PersistentVolumeClaim. O PersistentVolumeClaim não está vinculado a um PersistentVolume.

O erro 100020104 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha porque o PersistentVolumeClaim não está vinculado a um PersistentVolume. O erro resulta na seguinte mensagem: Failed to backup PVC - PVC Not Bound to a Persistent Volume.

Esse erro ocorre quando a operação do Backup para GKE tenta fazer backup de um PersistentVolumeClaim que não está vinculado a um PersistentVolume. Um PersistentVolumeClaim precisa ser vinculado a um PersistentVolume antes de poder ser usado por uma carga de trabalho consumidora, como um pod, e posteriormente fazer backup com o Backup para GKE. Se o PersistentVolumeClaim permanecer no estado Pending, isso significa que um PersistentVolume adequado não está disponível ou não pode ser provisionado ou vinculado, o que leva à falha da operação de backup. Um motivo comum para um PersistentVolumeClaim permanecer não vinculado é quando o StorageClass associado usa um modo de vinculação WaitForFirstConsumer, mas nenhum pod ou outra carga de trabalho ainda está tentando consumir o PersistentVolumeClaim.

Para resolver esse erro, siga estas instruções:

  1. Para verificar o status de todos os PersistentVolumeClaims no cluster e identificar os PersistentVolumeClaim não vinculados, execute o comando kubectl get pvc:

    kubectl get pvc --all-namespaces | grep `Pending`
    
  2. Depois de identificar o PersistentVolumeClaim que não está vinculado a um PersistentVolume, recupere informações sobre o PersistentVolumeClaim não vinculado executando o comando kubectl describe pvc:

    kubectl describe pvc PVC_NAME -n NAMESPACE_NAME
    

    Substitua:

    • PVC_NAME: o nome do PersistentVolumeClaim que não foi possível fazer backup.

    • NAMESPACE_NAME: o nome do namespace em que o PersistentVolumeClaim reside.

    Depois que a descrição aparecer, use os campos Status e Events para determinar se o PersistentVolumeClaim está vinculado a um PersistentVolume. Se você ainda não conseguir determinar por que o PersistentVolumeClaim não está vinculado a um PersistentVolume ou não conseguir resolver o problema identificado, ative o modo permissivo no seu plano de backup. Para saber mais sobre como ativar o modo permissivo, consulte Ativar o modo permissivo em um plano de backup.

A seguir