Configuração de Política para Criação e Implantação de Cluster

Saiba mais sobre as políticas do IAM a serem criadas antes de usar o Kubernetes Engine (OKE).

Quando uma tenancy é criada, um grupo chamado Administradores é criado automaticamente para a tenancy. Os usuários que são membros do grupo Administradores podem executar qualquer operação nos recursos da tenancy. Se todos os usuários que estiverem trabalhando com o Kubernetes Engine já forem membros do grupo Administradores, não haverá necessidade de criar outras políticas.

No entanto, se você quiser permitir que os usuários que não são membros do grupo Administradores usem o Serviço Kubernetes Engine, crie políticas para permitir que os grupos aos quais esses usuários pertencem executem operações em recursos na tenancy ou em compartimentos individuais. Algumas políticas são obrigatórias, algumas são opcionais. Consulte Criar Política Obrigatória para Grupos e Criar Uma ou Mais Políticas Adicionais para Grupos.

Você também precisará criar políticas adicionais se quiser:

Se você quiser que grupos de usuários em uma tenancy acessem recursos relacionados ao cluster em outras tenancies, crie instruções especiais de política entre tenancies que declarem explicitamente os recursos que podem ser acessados e compartilhados. Consulte Acessando Recursos Relacionados ao Cluster entre Tenancies.

Observe que, bem como as políticas acima gerenciadas pelo serviço IAM, você também pode usar o Autorizador do Kubernetes RBAC para impor controle de acesso detalhado adicional para usuários em clusters específicos por meio de atribuições e clusterroles do Kubernetes RBAC. Consulte Sobre o Controle de Acesso e o Serviço Kubernetes Engine (OKE).

Criar Política Obrigatória para Grupos

Para criar, atualizar e excluir clusters e pools de nós, os usuários que não forem membros do grupo Administradores deverão ter permissões para trabalhar com recursos relacionados ao cluster. Para conceder aos usuários o acesso necessário, crie uma política com várias instruções de política necessárias para os grupos aos quais esses usuários pertencem:

  1. Abra o menu de navegação e clique em Identidade e Segurança. Em Identidade, clique em Políticas. É exibida uma lista das políticas no compartimento que você está exibindo.
  2. Selecione o compartimento raiz da tenancy ou um compartimento individual contendo recursos relacionados ao cluster na lista à esquerda.
  3. Clique em Criar Política.
  4. Informe o seguinte:

    • Nome: Um nome para a política (por exemplo, acme-dev-team-oke-required-policy) que é exclusivo no compartimento. Se você estiver criando a política no compartimento raiz da tenancy, o nome deverá ser exclusivo em todas as políticas na sua tenancy. Não é possível alterá-lo posteriormente. Evite fornecer informações confidenciais.
    • Descrição: Uma descrição amigável. Você poderá alterá-la posteriormente, se desejar.
    • Instrução: As seguintes instruções de política obrigatórias para permitir que os usuários usem o Kubernetes Engine para criar, atualizar e excluir clusters e pools de nós:

      Allow group <group-name> to manage instance-family in <location>
      Allow group <group-name> to use subnets in <location>
      Allow group <group-name> to manage virtual-network-family in <location>
      Allow group <group-name> to inspect compartments in <location>
      Allow group <group-name> to use vnics in <location>
      Allow group <group-name> to use network-security-groups  in <location>
      Allow group <group-name> to use private-ips  in <location>
      Allow group <group-name> to manage public-ips  in <location>

      A seguinte instrução de política obrigatória para permitir que os usuários executem qualquer operação em recursos relacionados ao cluster (essa política "catch-all" torna efetivamente todos os usuários administradores no que diz respeito aos recursos relacionados ao cluster):

      Allow group <group-name> to manage cluster-family in <location>

      Nas instruções de política acima, substitua <location> por tenancy (se você estiver criando a política no compartimento raiz da tenancy) ou por compartment <compartment-name> (se você estiver criando a política em um compartimento individual).

      Observação

      Observe que, dependendo do tipo de cluster, algumas instruções de política obrigatórias podem não ser necessárias:
      • Para trabalhar com clusters "nativos da VCN" (em que o ponto final da API do Kubernetes é totalmente integrado à sua VCN), o use private-ips é sempre necessário. No entanto, a instrução de política use public-ips só será necessária se a opção de endereço IP público dos clusters for selecionada. Para obter mais informações sobre clusters nativos da VCN, consulte Plano de Controle de Cluster do Kubernetes e API do Kubernetes.
      • Para trabalhar com clusters em que o ponto final público de API do Kubernetes está em uma tenancy gerenciada pela Oracle, as instruções de política use vnics, use private-ips e use public-ips são desnecessárias.

      Observe que, se um grupo não estiver no domínio de identidades padrão, coloque o nome do grupo no formato group '<identity-domain-name>'/'group-name' como prefixo. Você também pode especificar um grupo usando seu OCID, no formato group id <group-ocid>.

    • Tags: Se você tiver permissões para criar um recurso, também terá permissões para aplicar tags de formato livre a esse recurso. Para aplicar uma tag definida, você deve ter permissões para usar o namespace da tag. Para obter mais informações sobre tags, consulte Tags de Recursos. Se você não tiver certeza se deseja aplicar tags, ignore esta opção ou pergunte a um administrador. Você pode aplicar tags posteriormente.
  5. Clique em Criar.

Criar Uma ou Mais Políticas Adicionais para Grupos

Para ativar usuários que não são membros do grupo Administradores a usar o Serviço Kubernetes Engine, crie políticas adicionais para permitir que os grupos aos quais esses usuários pertencem executem operações em recursos relacionados ao cluster da seguinte forma:

  1. Abra o menu de navegação e clique em Identidade e Segurança. Em Identidade, clique em Políticas. É exibida uma lista das políticas no compartimento que você está exibindo.
  2. Selecione o compartimento raiz da tenancy ou um compartimento individual contendo recursos relacionados ao cluster na lista à esquerda.
  3. Clique em Criar Política.
  4. Informe o seguinte:

    • Nome: um nome para a política (por exemplo, acme-dev-team-oke-additional-policy) que seja exclusivo no compartimento. Se você estiver criando a política no compartimento raiz da tenancy, o nome deverá ser exclusivo em todas as políticas na sua tenancy. Não é possível alterá-lo posteriormente. Evite fornecer informações confidenciais.
    • Descrição: Uma descrição amigável. Você poderá alterá-la posteriormente, se desejar.
    • Instrução: uma instrução de política adequada para permitir que grupos existentes executem operações em recursos relacionados ao cluster. Nas instruções de política abaixo, substitua <location> por tenancy (se você estiver criando a política no compartimento raiz da tenancy) ou por compartment <compartment-name> (se você estiver criando a política em um compartimento individual):

      • Para permitir que os usuários do grupo acme-dev-team criem e configurem automaticamente novos recursos de rede associados ao criar novos clusters no workflow 'Criação Rápida', as políticas também devem conceder ao grupo:

        • Permissões VCN_READ e VCN_CREATE. Digite uma instrução de política como:

          Allow group acme-dev-team to manage vcns in <location>
        • Permissões SUBNET_READ e SUBNET_CREATE. Digite uma instrução de política como:

          Allow group acme-dev-team to manage subnets in <location>
        • Permissão INTERNET_GATEWAY_CREATE. Digite uma instrução de política como:

          Allow group acme-dev-team to manage internet-gateways in <location>
        • Permissão NAT_GATEWAY_CREATE. Digite uma instrução de política como:

          Allow group acme-dev-team to manage nat-gateways in <location>
        • Permissão ROUTE_TABLE_UPDATE. Digite uma instrução de política como:

          Allow group acme-dev-team to manage route-tables in <location>
        • Permissão SECURITY_LIST_CREATE. Digite uma instrução de política como:

          Allow group acme-dev-team to manage security-lists in <location>
      • Para permitir que os usuários do grupo acme-dev-team-cluster-viewers simplesmente listem os clusters, digite uma instrução de política como:

        Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>
      • Para permitir que os usuários do grupo acme-dev-team-pool-admins listem, criem, atualizem e excluam pools de nós, digite uma instrução de política como:

        Allow group acme-dev-team-pool-admins to use cluster-node-pools in <location>
      • Para permitir que os usuários do grupo acme-dev-team-auditors vejam detalhes das operações executadas em clusters, digite uma instrução de política como:

        Allow group acme-dev-team-auditors to read cluster-work-requests in <location>
      • Para permitir que os usuários do grupo acme-dev-team-sgw criem um gateway de serviço para permitir que os nós de trabalho acessem outros recursos na mesma região sem expor dados à Internet pública, digite uma instrução de política como:

        Allow group acme-dev-team-sgw to manage service-gateways in <location>
      • Para permitir que os usuários do grupo acme-dev-team acessem clusters usando o Cloud Shell, digite uma instrução de política como:

        Allow group acme-dev-team to use cloud-shell in <location>

        Observe que, para acessar clusters usando o Cloud Shell, você também precisará configurar o arquivo kubeconfig corretamente (consulte Configurando o Acesso do Cloud Shell a Clusters). Para obter mais informações sobre o Cloud Shell, consulte Cloud Shell.

      • Para permitir que os usuários do grupo acme-dev-team selecionem chaves e vaults de criptografia principais no serviço Vault ao criar e modificar clusters usando a Console:
        Allow group acme-dev-team to read vaults in <location>
        Allow group acme-dev-team to read keys in <location>
      • Para permitir que os usuários do grupo acme-dev-team usem reservas de capacidade:
        Allow group acme-dev-team to use compute-capacity-reservations in <location>

        Para obter mais informações, consulte Usando Reservas de Capacidade para Provisionar Nós Gerenciados

      Observação

      Observe que, se um grupo não estiver no domínio de identidades padrão, coloque o nome do grupo no formato group '<identity-domain-name>'/'group-name' como prefixo. Você também pode especificar um grupo usando seu OCID, no formato group id <group-ocid>.

    • Tags: Se você tiver permissões para criar um recurso, também terá permissões para aplicar tags de formato livre a esse recurso. Para aplicar uma tag definida, você deve ter permissões para usar o namespace da tag. Para obter mais informações sobre tags, consulte Tags de Recursos. Se você não tiver certeza se deseja aplicar tags, ignore esta opção ou pergunte a um administrador. Você pode aplicar tags posteriormente.
  5. Clique em Criar.

Criar Política para Configurar e Usar Nós Virtuais

Para criar e usar clusters com nós virtuais e pools de nós virtuais, você sempre precisa configurar pelo menos uma política do serviço IAM, que é necessária em todas as circunstâncias pelos administradores da tenancy e pelos usuários não administradores. Para permitir que usuários não administradores usem nós virtuais, você também deve configurar uma política adicional. Em resumo, as políticas:

  • Endossar o serviço Kubernetes Engine para permitir que nós virtuais criem instâncias de contêiner na tenancy do serviço Kubernetes Engine com uma VNIC conectada a uma sub-rede de uma VCN em sua tenancy.
  • Conceda aos usuários não administradores as permissões necessárias.

Para obter mais informações sobre as instruções de política a serem especificadas, consulte Políticas Obrigatórias do Serviço IAM para Usar Nós Virtuais.

Criar Política para Acessar Chaves de Criptografia Gerenciadas pelo Usuário para Criptografar Volumes de Inicialização, Volumes em Blocos e/ou Sistemas de Arquivos

Para especificar uma chave de criptografia principal gerenciada pelo usuário específica do serviço Vault para criptografar dados em volumes de inicialização, volumes em blocos e/ou sistemas de arquivos, crie uma política para permitir o acesso a essa chave de criptografia principal. Para obter mais informações sobre como especificar chaves de criptografia gerenciadas pelo usuário:

Observe que, antes de criar a política, você precisa saber o OCID da chave de criptografia principal (consulte Gerenciando Chaves).

Para criar uma política que permita o acesso a uma chave de criptografia mestra gerenciada pelo usuário:

  1. Abra o menu de navegação e clique em Identidade e Segurança. Em Identidade, clique em Políticas. É exibida uma lista das políticas no compartimento que você está exibindo.
  2. É exibida uma lista das políticas no compartimento que você está exibindo.
  3. Selecione o compartimento raiz da tenancy ou um compartimento individual contendo recursos relacionados ao cluster na lista à esquerda.
  4. Clique em Criar Política, siga as instruções em Para criar uma política e dê um nome à política (por exemplo, acme-oke-keys-policy).
  5. Para volumes de inicialização: Para usar uma chave de criptografia principal do serviço Vault para criptografar dados em volumes de inicialização, digite as seguintes instruções de política para conceder acesso à chave de criptografia principal:

    Allow group <group-name> to read keys in compartment <compartment-name> where target.key.id = '<key_OCID>'
    
    Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>'
    
    Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key_OCID>'
    
    Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type='nodepool', target.key.id = '<key_OCID>'}

    em que:

    • <group-name> é um grupo ao qual você pertence. Observe que, se um grupo não estiver no domínio de identidades padrão, coloque o nome do grupo no formato group '<identity-domain-name>'/'group-name' como prefixo. Você também pode especificar um grupo usando seu OCID, no formato group id <group-ocid>.
    • <compartment-name> é o nome do compartimento que contém a chave de criptografia mestra.
    • <key-OCID> é o OCID da chave de criptografia mestra no serviço Vault.

    Por exemplo:

    Allow group acme-dev-team to read keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
    Allow service oke to use key-delegates in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
    Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
    Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type='nodepool', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}
  6. Para volumes em blocos: Para usar uma chave de criptografia principal do serviço Vault para criptografar dados em volumes em blocos, digite instruções de política para conceder acesso à chave de criptografia principal no formato:

    Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key-ocid>'
    
    Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key-ocid>'}

    em que:

    • <compartment-name> é o nome do compartimento que contém a chave de criptografia mestra.
    • <key-OCID> é o OCID da chave de criptografia mestra no serviço Vault.

    Por exemplo:

    Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
    Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}
  7. Para sistemas de arquivos: Para usar uma chave de criptografia principal do serviço Vault para criptografar dados em sistemas de arquivos, informe instruções de política para conceder acesso à chave de criptografia principal no formato:

    Allow dynamic-group <dynamic-group-name> to use keys in compartment <key-compartment-name>
    
    Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key_OCID>'}

    em que:

    • <dynamic-group-name> é o nome do grupo dinâmico de sistemas de arquivos no compartimento.

      Veja a seguir um exemplo de regra para o grupo dinâmico:

      ALL { resource.type='filesystem', resource.compartment.id = '<file_system_compartment_OCID>' }

      Observe que, se um grupo dinâmico não estiver no domínio de identidades padrão, coloque o nome do grupo dinâmico como prefixo com o nome do domínio de identidades no formato dynamic-group '<identity-domain-name>'/'<dynamic-group-name>'. Você também pode especificar o grupo dinâmico usando seu OCID, no formato dynamic-group id <dynamic-group-ocid>.

    • <compartment-name> é o nome do compartimento que contém a chave de criptografia mestra.
    • <key_OCID> é o OCID da chave mestre de criptografia no Vault.

    Por exemplo:

    Allow dynamic-group FssFileSystems to use keys in compartment acme-kms-key-compartment
    Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}
  8. Clique em Criar.