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

No Google Distributed Cloud (GDC) air-gapped, existe uma restrição que impede os utilizadores de excederem uma política de retenção máxima definida GDCHRestrictAttributeRange. Esta restrição é aplicada aos recursos personalizados (CRs) de contentores nos clusters de administrador da organização pelo Policy Controller do Anthos Config Management. Isto significa que, por predefinição, apenas as contas de serviço do sistema, os utilizadores do sistema e os utilizadores no grupo system:masters podem remover os finalizadores. O procedimento descrito abrange a forma de aumentar os limites da Política de Retenção nos CRs de contentores.

Pré-requisitos

Gere o ficheiro KUBECONFIG para o cluster

Os comandos Kubectl requerem um ficheiro KUBECONFIG válido para funcionar. Este processo fornece instruções passo a passo para gerar o ficheiro KUBECONFIG para o administrador principal, o administrador da organização, o sistema da organização e os clusters de utilizadores.

Pré-requisitos

Antes de continuar, certifique-se de que tem o seguinte:

  • O gdcloud está instalado.

  • A CLI kubectl está instalada.

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

  • O nome da organização.

  • O URL raiz (GDC). O administrador de TI da OC tem de lhe fornecer o URL raiz.

Defina as variáveis de ambiente necessárias

Siga as instruções nesta secção para gerar o ficheiro KUBECONFIG para o org-admin, o system ou qualquer cluster de utilizadores.

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

    export ORG=

  2. Execute o seguinte comando para definir a variável de ambiente CONSOLE_URL para utilização 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 base do seu projeto do GDC.

Inicie sessão no cluster

  1. Execute o seguinte comando para iniciar sessão:

    gdcloud auth login --no-browser

  2. Copie o comando gdcloud que é impresso e execute-o numa máquina com acesso ao navegador.

  3. Copie o URL impresso e cole-o na barra de endereço de um navegador de Internet.

  4. Siga as instruções na página Web para concluir o processo de início de sessão.

  5. Após a conclusão com êxito do início de sessão, o navegador apresenta a mensagem Autenticação bem-sucedida. Feche esta janela.

  6. Siga as instruções no terminal. Após o início de sessão com êxito, o terminal apresenta a mensagem Tem sessão iniciada.

Gere o ficheiro KUBECONFIG

  1. Execute o seguinte comando para definir a variável de ambiente CLUSTER para utilização posterior no terminal atual. CLUSTER é o nome do cluster pretendido.

    export CLUSTER=

    Consulte a tabela seguinte para obter o nome do cluster substituindo ORGANIZATION-NAME e CLUSTER-NAME pelos valores adequados:

    Cluster Nome do cluster
    administrador raiz root-admin
    admin. org. ORGANIZATION-NAME-admin
    sistema organizacional ORGANIZATION-NAME-system
    utilizador CLUSTER-NAME

    Verifica que cada um dos nomes representa o seguinte:

    • O nome do cluster de administrador principal é root-admin.
    • Os nomes do administrador da organização e do cluster do sistema da organização para uma organização denominada amira são amira-admin e amira-system, respetivamente.
    • Os nomes dos clusters de utilizadores são os respetivos nomes de clusters.

  2. Execute o seguinte comando para gerar o ficheiro 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 deve devolver o seguinte resultado:

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

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

Este processo ajuda a obter acesso temporário elevado a um cluster.

Pré-requisitos

Antes de continuar, certifique-se de que tem o seguinte:

  • Outro IO para atuar como aprovador de pedidos do GitLab. O IO tem de ter autorizações para aprovar um pedido do GitLab.
  • O nome do cluster ao qual precisa de acesso. Por exemplo: root-admin, org-1-admin.
  • O tipo de função que quer assumir. Por exemplo: Role ClusterRole, ProjectRole ou OrganizationRole.
  • A função que quer assumir.
  • O espaço de nomes do acesso necessário. Não é necessário para ClusterRole e OrganizationRole.
  • Acesso a uma estação de trabalho de TI do OC.
  • Credenciais para o GitLab.

Execute o script elevated-access-script

  1. A partir do diretório private-cloud/operations/tools/ na sua estação de trabalho, execute o script elevated-access-script.sh.

  2. Responda à pergunta "Introduza o GDCH_URL do cluster…" com $GDCH_URL.

  3. Responda à pergunta "Introduza o nome de utilizador do Gitlab:" com o nome de utilizador que usa para iniciar sessão no Gitlab.

  4. Para a pergunta "Introduza o token de acesso pessoal do Gitlab:", introduza o token de acesso pessoal da sua conta. Para criar um token de acesso pessoal, siga estas instruções:

    1. Aceda a https://gitlab.$GDCH_URL/gdch/iac. Inicie sessão na sua conta do IO Gitlab.

    2. Selecione o seu avatar.

    3. Selecione Editar perfil.

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

    5. Introduza um nome e uma data de validade para o token.

    6. Selecione os âmbitos pretendidos.

    7. Selecione Criar token de acesso pessoal.

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

  6. Responda à pergunta "Introduza o prefixo do IdP". O IdP Prefix é um prefixo específico de cada fornecedor de identidade que é adicionado antes de cada nome de utilizador num cluster da GDC. Pode encontrar este prefixo de uma das seguintes formas:

    • consultar o seu Watch Commander
    • Obter instruções da configuração do GDC, especificamente da secção "Gestão de identidade e acesso" no guia do utilizador de operadores.

    A forma habitual deste prefixo é um conjunto de palavras seguido de um delimitador, ou seja, gdch-infra-operator-.

  7. Responda à pergunta "Introduza o seu nome de utilizador" com o nome de utilizador que usa para iniciar sessão no seu fornecedor de identidade.

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

  9. O script pede-lhe que escolha um tipo de função do Kubernetes. Escreva o tipo de função que está a pedir.

  10. Responda à pergunta "Introduza a função que tem de assumir" com o nome da função.

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

  12. O script gera três ficheiros 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 que cada ficheiro está correto premindo Y ou prima N para editar o ficheiro em vim.

  13. Depois de confirmar todos os ficheiros, o script envia-os para um ramo elevated_access no GitLab e cria um pedido de união.

Reveja e aprove o pedido de acesso elevado

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

  1. Outro IO revê o pedido do GitLab, incluindo os ficheiros de configuração de políticas, para aprovar o pedido de forma adequada.
  2. Assim que a OI aprovar o pedido, o sistema concede acesso durante o período pedido.
  3. O sistema revoga o acesso após o tempo de expiração definido.

Restrição de patch

Depois de obter o acesso necessário, execute o seguinte comando para definir o novo máximo da política de retenção do contentor. Este exemplo mostra um novo máximo de 120 dias, mas certifique-se de que atualiza o comando para o valor pedido pelo administrador da plataforma (PA):

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

O resultado deve ter o seguinte aspeto:

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