Configurar políticas da organização

As políticas da organização oferecem controle centralizado e programático sobre os recursos da organização. Como administrador de políticas da organização, é possível configurar políticas em toda a organização para alcançar os seguintes benefícios:

  • Centralize o controle para configurar restrições sobre como usar os recursos da sua organização.
  • Defina e estabeleça proteções para que suas equipes de desenvolvimento permaneçam dentro dos limites de conformidade.
  • Ajudar os proprietários de projetos e as equipes deles a avançar rapidamente sem violar a conformidade.

O Google Distributed Cloud (GDC) com isolamento físico não oferece uma UI do console ou uma CLI dedicada para criar e gerenciar políticas da organização. É preciso usar a API Kubernetes ou a CLI kubectl.

Diferenças do gerenciamento de identidade e acesso

O Identity and Access Management (IAM) e as políticas da organização têm funções complementares de acesso e governança:

  • O IAM se concentra na concessão de permissões. Ela define quem (membros como usuários, grupos ou contas de serviço) pode realizar quais ações (papéis) em quais recursos (escopo do recurso). As permissões concedidas por papéis do IAM são aditivas e não têm regras de negação.
  • As políticas da organização se concentram em estabelecer proteções. Eles permitem que os administradores configurem restrições programáticas em recursos em toda a organização, como desativar serviços específicos ou restringir modificações de recursos com base em atributos de assunto usando o controle de acesso baseado em atributos (ABAC). As políticas da organização têm precedência para bloquear operações, mesmo que um membro tenha um papel do IAM.

Antes de começar

Antes de configurar as políticas da organização, solicite as permissões necessárias e prepare o ambiente.

Solicitar papéis do IAM

Entre em contato com o admin. da organização do IAM para solicitar os seguintes papéis do IAM com base nas tarefas que você precisa realizar:

  • Administrador de políticas de serviço restrito (gdchrestrictedservice-policy-admin): criar, atualizar e excluir políticas de serviço restrito.
  • Administrador da política de restrição por atributos (gdchrestrictbyattributes-policy-admin): criar, atualizar e excluir políticas de controle de acesso com base em atributos.

Preparar o ambiente

Configurar uma política

É possível configurar dois tipos de políticas da organização no GDC:

  • Política de serviço restrito (GDCHRestrictedService): restringe quais serviços podem ser usados ou modificados em um cluster.
  • Política de controle de acesso com base em atributos (GDCHRestrictByAttributes): restringe condicionalmente o acesso a recursos em um cluster com base em atributos de assunto mapeados do seu provedor de identidade.

Configurar uma política de serviço restrito

O tipo de política GDCHRestrictedService permite restringir quais serviços podem ser usados ou modificados em um cluster bloqueando APIs específicas, como restringir um serviço a determinados projetos ou bloquear o acesso a um novo serviço enquanto você o testa. Crie essa política no mesmo cluster que os recursos de serviço. É possível criar várias instâncias de política em um cluster para diferentes serviços ou projetos.

O GDCHRestrictedService é compatível com as operações CREATE, UPDATE e DELETE. Para restringir as operações de leitura de GET e LIST, use as vinculações de papéis do IAM para conceder e revogar o acesso.

Configure uma política de serviço restrito:

  1. Defina o manifesto da política:

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: POLICY_NAME
spec:
  match:
    kinds:
      - apiGroups:
          - "API_GROUP"
        kinds:
          - "KIND"
  parameters:
    disabledOperations:
      - DISABLED_OPERATION

    Substitua:

    • POLICY_NAME: o nome da política da organização.

    • API_GROUP: o grupo de APIs do serviço a ser restrito, conforme listado na tabela de serviços compatíveis a seguir.

    • KIND: o tipo de recurso a ser restrito, conforme listado na tabela de serviços compatíveis a seguir.

    • DISABLED_OPERATION: os grupos de operações que essa política bloqueia. Os valores permitidos são CREATE, UPDATE e DELETE. O valor padrão do campo disabledOperations é *. Para desativar completamente um serviço, liste CREATE, UPDATE e DELETE (e especifique todos os tipos).

    Por padrão, a política se aplica a todos os namespaces no cluster. Para definir o escopo da política para namespaces ou projetos específicos, consulte Definir o escopo de uma política da organização em um cluster.

    A política GDCHRestrictedService é compatível com o seguinte subconjunto de serviços no GDC:

    Serviço Grupo de APIs kinds
    Marketplace marketplace.gdc.goog MarketplaceService
    Vertex AI Workbench aiplatform.gdc.goog Notebook
    Serviço de banco de dados: Postgres postgresql.dbadmin.gdc.goog
    • DBCluster
    • BackupPlan
    • Import
    • Restore
    Transfer Appliance system.gpc.gke.io TransferApplianceRequest
    Backup backup.gdc.goog BackupRepositoryManager
    Contêiner do Dataproc para Spark (serviço do Marketplace) sparkoperator.k8s.io SparkApplication

    Se um serviço listar vários tipos na tabela (como o Serviço de banco de dados), especifique apenas os tipos individuais que você quer restringir. Por exemplo, é possível bloquear operações Restore e continuar permitindo operações DBCluster.

    O exemplo a seguir restringe as atualizações aos serviços do marketplace:

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: no-update-to-marketplace-service
spec:
  match:
    kinds:
    - apiGroups:
      - "marketplace.gdc.goog"
      kinds:
      - MarketplaceService
  parameters:
    disabledOperations:
      - "UPDATE"

  2. Aplique a política usando a CLI kubectl:

    kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f POLICY_NAME.yaml

    Substitua:

    • CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster em que você quer aplicar a política.
    • POLICY_NAME: o nome do arquivo da política da organização

Configurar uma política de controle de acesso baseado em atributos

O tipo de política GDCHRestrictByAttributes permite criar políticas de ABAC para restringir condicionalmente o acesso a recursos com base em atributos de assunto. Por exemplo, é possível usar esse tipo de política para restringir operações de gravação ou modificação em buckets de armazenamento, de modo que apenas usuários ou contas de serviço com atributos de identidade específicos (como citizenship=USA ou citizenship=UK) possam realizá-las.

Crie essa política no mesmo cluster dos recursos. É possível criar várias instâncias de política em um cluster para diferentes recursos ou projetos.

Configure uma política de controle de acesso baseada em atributos:

  1. Crie um arquivo JSON de patch para mapear atributos de identidade personalizados para o recurso IdentityProviderConfig:

    cat <<EOF > attributeMapping-patch.json
{
  "CUSTOM_ATTRIBUTE": "assertion[\"CUSTOM_ATTRIBUTE\"]"
}
EOF

    Substitua CUSTOM_ATTRIBUTE pelo nome do atributo de identidade a ser mapeado, como citizenship.

  2. Aplique um patch ao recurso IdentityProviderConfig no namespace platform:

    kubectl --kubeconfig CLUSTER_KUBECONFIG patch \
    IdentityProviderConfig IDENTITY_PROVIDER_CONFIG_NAME \
    -n platform --type=json \
    -p '[{"op":"add","path":"/spec/oidc/attributeMapping", "value": '"$(cat attributeMapping-patch.json)"'}]'

    Substitua:

    • CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster em que o provedor de identidade reside.
    • IDENTITY_PROVIDER_CONFIG_NAME: o nome do recurso IdentityProviderConfig.

  3. Defina o manifesto da política:

    apiVersion: constraints.global.gatekeeper.sh/v1beta1
kind: GDCHRestrictByAttributes
metadata:
  name: POLICY_NAME
spec:
  match:
    kinds:
      - apiGroups:
          - "API_GROUP"
        kinds:
          - "KIND"
  parameters:
    attributes:
      - CUSTOM_ATTRIBUTE
    attributeValues:
      - ALLOWED_ATTRIBUTE_VALUE

    Substitua:

    • POLICY_NAME: o nome da política da organização.

    • API_GROUP: o grupo de APIs dos recursos a serem restringidos, como object.gdc.goog.

    • KIND: o tipo de recurso a ser restrito, como Bucket.

    • CUSTOM_ATTRIBUTE: o atributo de assunto personalizado mapeado do provedor de identidade, como citizenship.

    • ALLOWED_ATTRIBUTE_VALUE: o valor permitido para o atributo personalizado, como USA. As solicitações de indivíduos cujo atributo não corresponde a um dos valores permitidos são negadas.

    Por padrão, a política se aplica a todos os namespaces no cluster. Para definir o escopo da política para namespaces ou projetos específicos, consulte Definir o escopo de uma política da organização em um cluster.

    O exemplo a seguir restringe a modificação de recursos Bucket no namespace project-foo a indivíduos com o atributo citizenship=USA ou citizenship=UK:

    apiVersion: constraints.global.gatekeeper.sh/v1beta1
kind: GDCHRestrictByAttributes
metadata:
  name: restrict-by-citizenship
spec:
  match:
    scope: Namespaced
    kinds:
      - apiGroups:
          - "object.gdc.goog"
        kinds:
          - Bucket
    namespaces:
      - project-foo
  parameters:
    attributes:
      - "citizenship"
    attributeValues:
      - "USA"
      - "UK"

  4. Aplique a política usando a CLI kubectl:

    kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f POLICY_NAME.yaml

    Substitua:

    • CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster em que você quer aplicar a política.
    • POLICY_NAME: o nome do arquivo da política da organização

Definir o escopo de uma política da organização em um cluster

Ao definir uma política da organização, decida se ela deve afetar todos os namespaces, apenas namespaces específicos ou todos os namespaces, exceto uma determinada lista. Para isso, use uma combinação dos parâmetros .spec.match.excludedNamespaces, .spec.match.namespaceSelector, .spec.match.namespaces e .spec.match.scope da definição da política.

Leia a página da seção de correspondência da política da organização para saber mais sobre esses parâmetros. Por exemplo, para permitir a criação de bancos de dados apenas em namespaces que tenham o rótulo owner: dba-team, crie a seguinte política:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: db-restricted-to-dbas
spec:
  match:
    scope: Namespaced
    namespaceSelector:
      matchExpressions:
      # We are restricting the use of the service in namespaces that
      # don't have the owner: dba-team label
      - key: owner
        operator: NotIn
        values:
        - dba-team
    kinds:
    - apiGroups:
      - "postgresql.dbadmin.gdc.goog"
      kinds:
      - DBCluster
      - BackupPlan
      - Import
      - Restore
  parameters:
    disabledOperations:
      - "UPDATE"
      - "CREATE"
      - "DELETE"

Reverter uma política atual

Para interromper a aplicação de uma política, exclua-a usando a CLI kubectl. Use um arquivo kubeconfig que dê acesso ao cluster em que a política está definida e ao papel do IAM correspondente ao tipo de política (como gdchrestrictedservice-policy-admin ou gdchrestrictbyattributes-policy-admin).

Exclua uma política da organização:

kubectl --kubeconfig CLUSTER_KUBECONFIG delete \
    POLICY_TYPE/POLICY_NAME

Substitua:

  • CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster em que a política da organização reside

  • POLICY_TYPE: o tipo de política da organização a ser excluída, como GDCHRestrictedService ou GDCHRestrictByAttributes.

  • POLICY_NAME: o nome da política da organização a ser excluída.

Testar uma política em um modo de auditoria

É possível testar uma política sem aplicá-la. Teste uma política para garantir que ela não interrompa os sistemas atuais antes de ser lançada ou para estimar a abrangência de um comportamento. Para adicionar um teste, adicione um enforcementAction à definição da política. Há três valores possíveis para esse parâmetro:

  • deny: a política é aplicada. Esta é a configuração padrão.
  • dryrun: a ação é permitida, mas é possível ver que há uma violação da política nos registros de auditoria e no status da política. Analise a violação com kubectl --kubeconfig CLUSTER_KUBECONFIG get POLICY_TYPE/POLICY_NAME.
  • warn: equivalente a dryrun, exceto que o teste também mostra um aviso em resposta à solicitação que acionou uma violação da política.

Por exemplo, para testar uma política que desativa o Marketplace, crie a seguinte política:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: disable-marketplace-service-project-alice
spec:
  enforcementAction: warn
  match:
    kinds:
      - apiGroups: ["marketplace.gdc.goog"]
        kinds: ["MarketplaceService"]