Aumentar os limites da política de retenção

No Google Distributed Cloud (GDC) com isolamento físico, há uma restrição que impede que os usuários excedam uma política de retenção máxima definida GDCHRestrictAttributeRange. Essa restrição é aplicada aos recursos personalizados (CRs, na sigla em inglês) de bucket nos clusters de administrador da organização pelo controlador de políticas do Anthos Config Management. Isso significa que somente as contas de serviço do sistema, os usuários do sistema e os usuários do grupo system:masters podem remover os finalizadores por padrão. O procedimento descrito aborda como aumentar os limites da política de retenção em CRs de bucket.

Pré-requisitos

Gere o arquivo KUBECONFIG do cluster

Os comandos do Kubectl exigem um arquivo KUBECONFIG válido para funcionar. Esse processo fornece instruções detalhadas para gerar o arquivo KUBECONFIG para o administrador raiz, administrador da organização, sistema da organização e clusters de usuário.

Pré-requisitos

Antes de continuar, verifique se você tem o seguinte:

  • O gdcloud está instalado.

  • A CLI kubectl está instalada.

  • Um certificado assinado de autoridade de certificação (CA) instalado na estação de trabalho.

  • O nome da organização.

  • O URL raiz do GDC. O administrador de TI do OC precisa fornecer o URL raiz.

Definir variáveis de ambiente obrigatórias

Siga as instruções nesta seção para gerar o arquivo KUBECONFIG para o org-admin, system ou qualquer cluster de usuário.

  1. Execute o comando a seguir para definir a variável de ambiente ORG para uso posterior no terminal atual. ORG é o nome da sua organização.

    export ORG=

  2. Execute o comando a seguir para definir a variável de ambiente CONSOLE_URL para uso posterior no terminal atual:

    export CONSOLE_URL=https://console.${ORG:?}.$GDC_URL/
gdcloud config set core/organization_console_url ${CONSOLE_URL:?}

    Substitua GDC_URL pelo URL de base do seu projeto do GDC.

Fazer login no cluster

  1. Execute o seguinte comando para fazer login:

    gdcloud auth login --no-browser

  2. Copie o comando gdcloud impresso e execute-o em uma máquina com acesso ao navegador.

  3. Copie o URL impresso e cole na barra de endereço de um navegador da Web.

  4. Siga as instruções na página da Web para concluir o processo de login.

  5. Quando o login é concluído, o navegador mostra a mensagem Autenticação bem-sucedida. Feche esta janela.

  6. Siga as instruções no terminal. Se o login for concluído, o terminal vai mostrar a mensagem Você fez login.

Gerar arquivo KUBECONFIG

  1. Execute o comando a seguir para definir a variável de ambiente CLUSTER para uso posterior no terminal atual. CLUSTER é o nome desejado para o cluster.

    export CLUSTER=

    Consulte a tabela a seguir para derivar o nome do cluster substituindo ORGANIZATION-NAME e CLUSTER-NAME pelos valores apropriados:

    Cluster Nome do cluster
    administrador raiz root-admin
    admin. da organização ORGANIZATION-NAME-admin
    sistema de organização ORGANIZATION-NAME-system
    usuário CLUSTER-NAME

    Cada um dos nomes representa o seguinte:

    • O nome do cluster de administrador raiz é root-admin.
    • Os nomes do administrador da organização e do cluster do sistema da organização para uma organização chamada amira são amira-admin e amira-system, respectivamente.
    • Os nomes dos clusters de usuário são os nomes deles.

  2. Execute o comando a seguir para gerar o arquivo KUBECONFIG e validar as credenciais: sh export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml rm ${KUBECONFIG:?} gdcloud clusters get-credentials ${CLUSTER:?} [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure" O comando vai retornar a seguinte saída:

    Success. Your kubeconfig is at /usr/local/google/home/iris/kubeconfig-amira-admin.yaml

Receber a função de administrador de políticas no cluster

Esse processo ajuda você a ter acesso elevado temporário a um cluster.

Pré-requisitos

Antes de continuar, verifique se você tem o seguinte:

  • Outro IO para atuar como aprovador de solicitações do GitLab. O IO precisa ter permissões para aprovar uma solicitação do GitLab.
  • O nome do cluster a que você precisa de acesso. Por exemplo: root-admin, org-1-admin.
  • O tipo de função que você quer assumir. Por exemplo, Role ClusterRole, ProjectRole ou OrganizationRole.
  • A função que você quer assumir.
  • O namespace do acesso necessário. Não é necessário para ClusterRole e OrganizationRole.
  • Acesso a uma estação de trabalho de TI da OC.
  • Credenciais do GitLab.

Executar elevated-access-script

  1. No diretório private-cloud/operations/tools/ da estação de trabalho, execute o script elevated-access-script.sh.

  2. Responda à pergunta "Please enter the GDCH_URL of the cluster..." com $GDCH_URL.

  3. Responda à pergunta "Enter Gitlab username:" com o nome de usuário que você usa para fazer login no GitLab.

  4. Na pergunta "Enter Gitlab personal access token:", insira o token de acesso pessoal da sua conta. Para criar um token de acesso pessoal, siga estas instruções:

    1. Acesse https://gitlab.$GDCH_URL/gdch/iac. Faça login na sua conta do IO Gitlab.

    2. Selecione seu avatar.

    3. Selecione Editar perfil.

    4. No menu de navegação, selecione Tokens de acesso.

    5. Insira um nome e uma data de expiração para o token.

    6. Selecione os escopos desejados.

    7. Selecione Criar token de acesso pessoal.

  5. O script vai clonar o repositório iac no seu diretório local.

  6. Responda à pergunta "Insira o prefixo do IdP". O IdP Prefix é um prefixo específico de cada provedor de identidade que é adicionado antes de cada nome de usuário em um cluster do GDC. Para encontrar esse prefixo, faça o seguinte:

    • consultar o comandante da guarda
    • recuperando instruções da configuração do GDC, especificamente a seção "Gerenciamento de identidade e acesso" no guia do usuário de operadores.

    A forma usual desse prefixo é um conjunto de palavras seguido por um delimitador, ou seja, gdch-infra-operator-.

  7. Responda à pergunta "Insira seu nome de usuário" com o nome de usuário que você usa para fazer login no provedor de identidade.

  8. Responda à pergunta "Insira o cluster para o qual você precisa da função" com o nome do cluster.

  9. O script vai pedir que você escolha um tipo de função do Kubernetes. Digite o tipo de função que você está solicitando.

  10. Responda à pergunta "Insira a função que você precisa assumir" com o nome da função.

  11. Insira a duração do acesso da função. A duração recomendada do acesso é de 3 horas.

  12. O script vai gerar três arquivos YAML.

    1. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/kustomization.yaml
    2. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/kustomization.yaml
    3. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/${ROLE}-binding.yaml

    Confirme se cada arquivo está correto pressionando Y ou pressione N para editar o arquivo em vim.

  13. Depois de confirmar todos os arquivos, o script vai enviar esses arquivos para uma ramificação elevated_access no GitLab e criar uma solicitação de mesclagem.

Analisar e aprovar o pedido de acesso elevado

A lista a seguir especifica as ações realizadas para uma solicitação de acesso elevado de revisão e aprovação:

  1. Outro IO analisa a solicitação do GitLab, incluindo os arquivos de configuração da política, para aprovar a solicitação adequadamente.
  2. Depois que a OI aprova a solicitação, o sistema concede acesso pelo período solicitado.
  3. O sistema revoga o acesso após o tempo de expiração definido.

Restrição de patch

Depois de receber o acesso necessário, execute o comando a seguir para definir o novo máximo da política de retenção do bucket. Este exemplo mostra um novo máximo de 120 dias, mas atualize o comando para o valor solicitado pelo administrador da plataforma (PA):

kubectl patch GDCHRestrictAttributeRange restrict-bucket-retention-policy -p '{"spec":{"parameters":{"attributeMaxValue":120}}}' --type=merge

A saída será semelhante a esta:

gdchrestrictattributerange.constraints.gatekeeper.sh/restrict-bucket-retention-policy patched