Algumas ou todas as informações nesta página podem não se aplicar à Trusted Cloud by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

Configure a autenticação de identidade de carga de trabalho gerida para o GKE

Este documento explica como configurar identidades de cargas de trabalho geridas para o Google Kubernetes Engine (GKE) nos seus clusters geridos por frotas do GKE. Também explica como implementar uma carga de trabalho e validar a identidade e o certificado da carga de trabalho.

A configuração e a utilização de identidades de cargas de trabalho geridas para o GKE envolvem os seguintes passos:

Configure o serviço de autoridade de certificação para emitir certificados para identidades de cargas de trabalho geridas.
Associe as ACs ao Workload Identity Pool.
Autorize identidades de cargas de trabalho geridas a pedir certificados ao conjunto da AC.
Implemente cargas de trabalho com identidades de cargas de trabalho geridas.

Workload Identity Pool gerido pela Google

Quando adiciona os seus clusters a frotas do GKE, as frotas criam automaticamente um conjunto do Workload Identity gerido pela Google que serve como raiz do seu domínio de confiança. O Workload Identity Pool gerido pela Google tem as seguintes restrições:

A Google gere totalmente o conjunto, pelo que não pode criar sub-recursos, como namespaces, identidades ou fornecedores de identidade.
O conjunto só pode ser usado para cargas de trabalho do GKE. Não pode adicionar outros tipos de cargas de trabalho, como VMs do Compute Engine, ao conjunto.
Todos os clusters no conjunto estão sujeitos ao modelo de igualdade do espaço de nomes do Kubernetes padrão. Isto significa que todos os clusters no conjunto são igualmente privilegiados. As cargas de trabalho executadas em qualquer um dos clusters no pool podem usar qualquer identidade que esteja no pool.

Configuração de vários projetos

Trusted Cloud recursos que usa neste documento, como clusters do GKE, a CA raiz e as CAs subordinadas, podem existir em projetos separados. Quando fizer referência a estes recursos, use a flag --project para especificar o projeto correto para cada recurso.

Antes de começar

Create or select a Trusted Cloud project.
- Create a Trusted Cloud project:
```
gcloud projects create PROJECT_ID
```
  Replace PROJECT_ID with a name for the Trusted Cloud project you are creating.
- Select the Trusted Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
  Replace PROJECT_ID with your Trusted Cloud project name.

Compreenda as identidades de carga de trabalho geridas.
Certifique-se de que tem, pelo menos, um cluster do GKE. Certifique-se de que os seus clusters estão a executar a versão 1.33.0-gke.2248000 ou posterior.
Adicione os seus clusters a frotas do GKE. Se o seu cluster for um cluster do Autopilot, omita --enable-workload-identity. O Fleets cria automaticamente um Workload Identity Pool gerido pela Google que funciona como um domínio de confiança.

Ative as frotas do GKE executando o seguinte comando:
```
gcloud container clusters update CLUSTER_NAME \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-fleet \
    --fleet-project=PROJECT_ID
```
Substitua o seguinte:
- CLUSTER_NAME: o nome do cluster do GKE que quer registar na frota do GKE
- PROJECT_ID: o ID do projeto anfitrião do dispositivo do GKE
Enable the IAM and Certificate Authority Service APIs:
```
gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com
```
Configure a CLI do Google Cloud para usar o projeto de faturação e de quota.
```
gcloud config set billing/quota_project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do projeto da frota.

Funções necessárias

Para receber as autorizações de que precisa para criar identidades de carga de trabalho geridas e aprovisionar certificados de identidade de carga de trabalho geridos, peça ao seu administrador para lhe conceder as seguintes funções da IAM no projeto:

Para criar e configurar identidades de cargas de trabalho geridas: Administrador do conjunto do Workload Identity do IAM (roles/iam.workloadIdentityPoolAdmin)
Para criar e configurar pools de ACs: Administrador de serviço de AC (roles/privateca.admin)

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Configure o serviço de AC para emitir certificados para identidades de cargas de trabalho geridas

Para configurar identidades de cargas de trabalho geridas para o GKE, primeiro tem de configurar uma autoridade de certificação (AC) e uma ou mais ACs subordinadas. Esta configuração é conhecida como uma hierarquia de ACs.

Pode usar pools de serviços de ACs para configurar esta hierarquia. Com esta hierarquia, o conjunto de ACs subordinadas emite os certificados de identidade de carga de trabalho X.509 para as suas cargas de trabalho.

Configure o seu conjunto de ACs de raiz

Para criar o conjunto de ACs raiz, faça o seguinte:

Crie o conjunto de ACs de raiz no nível Enterprise através da gcloud privateca pools create. Este nível destina-se à emissão de certificados de longa duração e baixo volume.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

Substitua o seguinte:

ROOT_CA_POOL_ID: um ID exclusivo para o conjunto de ACs raiz. O ID pode ter até 64 carateres e tem de conter apenas carateres alfanuméricos em minúsculas e maiúsculas, sublinhados ou hífenes. O ID do conjunto tem de ser exclusivo na região.
REGION: a região onde o grupo de ACs de raiz está localizado.
CA_PROJECT_ID: o ID do projeto no qual quer criar a AC raiz.

Para saber mais sobre os conjuntos de ACs, os níveis e as regiões, consulte o artigo Criar conjuntos de ACs.

Configure a sua AC de raiz

Crie uma AC de raiz no conjunto de ACs de raiz através do comando gcloud privateca roots create. Pode ser-lhe pedido que ative a AC de raiz se esta for a única AC no conjunto de ACs de raiz.

Para criar uma AC raiz, execute o seguinte comando:

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

Substitua o seguinte:

ROOT_CA_ID: um nome exclusivo para a AC raiz. O nome da AC pode ter até 64 carateres e tem de conter apenas carateres alfanuméricos em minúsculas e maiúsculas, sublinhados ou hífenes. O nome da AC tem de ser exclusivo na região.
ROOT_CA_POOL_ID: o ID do grupo de ACs de raiz.
ROOT_CA_CN: o nome comum da CA raiz.
ROOT_CA_ORGANIZATION: a organização da AC raiz.
KEY_ALGORITHM: o algoritmo da chave, por exemplo, ec-p256-sha256
REGION: a região onde o grupo de ACs de raiz está localizado.
CA_PROJECT_ID: o ID do projeto no qual criou a AC raiz.

Para mais informações sobre os campos subject para a CA, consulte Assunto.

Opcionalmente, pode criar CAs de raiz adicionais no seu conjunto de CAs de raiz. Isto pode ser útil para a rotação da AC raiz.

Configure ACs subordinadas

Opcionalmente, pode configurar ACs subordinadas. A configuração de ACs subordinadas pode ajudar com o seguinte:

Vários cenários de emissão de certificados: se tiver vários cenários de emissão de certificados, pode criar uma AC subordinada para cada cenário.
Melhor equilíbrio de carga: adicionar várias ACs subordinadas num conjunto de ACs ajuda a alcançar um melhor equilíbrio de carga dos pedidos de certificados.

Para criar um conjunto de ACs subordinado e uma AC subordinada, faça o seguinte:

Crie o conjunto de ACs subordinadas no nível DevOps, que se destina à emissão de certificados de curta duração e em grande volume.
```
gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=devops
```
Substitua o seguinte:
- SUBORDINATE_CA_POOL_ID: um ID exclusivo para o conjunto de ACs subordinado. O ID pode ter até 64 carateres e tem de conter apenas carateres alfanuméricos em minúsculas e maiúsculas, sublinhados ou hífenes. O ID do conjunto tem de ser exclusivo na região.
- REGION: a região na qual criar o conjunto de CA subordinado.
- CA_PROJECT_ID: o ID do projeto no qual criou a CA subordinada.
Para mais informações, consulte o artigo Criar conjuntos de ACs.
Crie um CA subordinado no conjunto de CAs subordinados. Não altere o modo de emissão baseado na configuração predefinido.
```
gcloud privateca subordinates create SUBORDINATE_CA_ID \
    --pool=SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --issuer-pool=ROOT_CA_POOL_ID \
    --issuer-location=REGION \
    --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --use-preset-profile=subordinate_mtls_pathlen_0 \
    --project=CA_PROJECT_ID \
    --auto-enable
```
Substitua o seguinte:
- SUBORDINATE_CA_ID: um nome exclusivo para a AC subordinada. O nome pode ter até 64 carateres e tem de conter apenas carateres alfanuméricos em minúsculas e maiúsculas, sublinhados ou hífens. O nome do conjunto tem de ser exclusivo na região.
- SUBORDINATE_CA_POOL_ID: o nome do conjunto de ACs subordinadas.
- REGION: a região onde se encontra o grupo de CA subordinado.
- ROOT_CA_POOL_ID: o ID do grupo de ACs de raiz.
- REGION: a região do grupo de ACs de raiz.
- SUBORDINATE_CA_CN: o nome comum da AC subordinada.
- SUBORDINATE_CA_ORGANIZATION: o nome da organização emissora da AC subordinada.
- KEY_ALGORITHM: o algoritmo da chave, por exemplo, ec-p256-sha256
- CA_PROJECT_ID: o ID do projeto no qual criou a CA subordinada.
Para mais informações sobre os campos subject para a CA, consulte Assunto.

Crie um ficheiro de configuração de emissão de certificados

Para associar ACs a Workload Identity Pools, estas têm de ter uma configuração de emissão de certificados. Opcionalmente, se precisar que as suas cargas de trabalho sejam autenticadas em vários domínios de confiança, também pode atualizar o conjunto com configurações de confiança.

Para configurar a configuração de emissão de certificados, crie um ficheiro de configuração de emissão de certificados. O formato do ficheiro é semelhante ao seguinte:

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

Substitua o seguinte:

REGION: as regiões onde as ACs estão localizadas.
CA_PROJECT_NUMBER: o número do projeto no qual criou o grupo de ACs subordinado. Para obter o número do projeto do projeto CA_PROJECT_ID, execute o seguinte comando:
```
gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"
```
SUBORDINATE_CA_POOL_ID: O nome do conjunto de ACs subordinadas.
ALGORITHM: opcional. O algoritmo de encriptação usado para gerar a chave privada. Os valores válidos são ECDSA_P256 (predefinição), ECDSA_P384, RSA_2048, RSA_3072 e RSA_4096.
DURATION: opcional. A duração da validade do certificado de entidade final, em segundos. O valor tem de estar compreendido entre 86 400 (1 dia) e 2 592 000 (30 dias). Se não for especificado, é usado o valor predefinido de 86 400 (1 dia). A validade real do certificado emitido também depende da CA emissora, uma vez que pode restringir a duração do certificado emitido.
ROTATION_WINDOW_PERCENTAGE: Opcional: a percentagem do tempo de vida do certificado em que é acionada uma renovação. O valor tem de estar entre 50 e 80. A predefinição é 50.

Crie o ficheiro de configuração de confiança

Por predefinição, as suas cargas de trabalho no mesmo domínio de confiança podem autenticar-se mutuamente através de identidades de cargas de trabalho geridas. Se quiser que as cargas de trabalho que se encontram em domínios de confiança diferentes se autentiquem mutuamente, tem de declarar explicitamente a relação de confiança no conjunto do Workload Identity. Para isso, crie um ficheiro de configuração de confiança que contenha um inlineTrustConfig que forneça certificados para cada domínio.

O ficheiro de configuração de fidedignidade contém um conjunto de âncoras de fidedignidade que a identidade da carga de trabalho gerida usa para validar certificados de pares. O ficheiro de configuração de confiança mapeia o domínio de confiança SPIFFE para os certificados da AC.

Para criar o ficheiro de configuração de fidedignidade, faça o seguinte:

Transfira os certificados.
```
gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
    --output-file=CERTIFICATE_PATH \
    --location=REGION
```
Substitua o seguinte:
- ROOT_CA_POOL_ID: o ID do grupo de ACs de raiz
- CERTIFICATE_PATH: o caminho para o qual o certificado codificado em PEM deve ser emitido
- REGION: a região do grupo de ACs de raiz

Crie um ficheiro denominado que contenha a sua configuração de confiança incorporada, com certificados no formato PEM. O ficheiro tem um aspeto semelhante ao seguinte:

{
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_NAME1": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      },
      "TRUSTED_DOMAIN_NAME2": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

Substitua o seguinte:

TRUST_DOMAIN_NAME: o nome do domínio de confiança, formatado da seguinte forma:
```
PROJECT_ID.svc.id.goog
```
CERTIFICATE_MATERIAL: um conjunto de certificados da AC no formato PEM fidedignos para emitir certificados no domínio de confiança.

Associe as ACs ao Workload Identity Pool

Depois de criar a hierarquia de ACs e as configurações de emissão de certificados para cada AC, associa as ACs ao Workload Identity Pool. Para associar uma AC ao Workload Identity Pool, atualize o Workload Identity Pool com a configuração de emissão de certificados da AC. Em seguida, pode verificar se o conjunto foi atualizado.

Atualize o Workload Identity Pool

Para atualizar o conjunto, execute o seguinte comando:

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Substitua o seguinte:

TRUST_DOMAIN_NAME: o nome do domínio fidedigno, formatado da seguinte forma:
```
PROJECT_ID.svc.id.goog
```
CIC_JSON_FILE_PATH: o caminho para o ficheiro de configuração de emissão de certificados (cic.json) formatado em JSON que criou anteriormente.
TC_JSON_FILE_PATH: opcional. O caminho para o ficheiro de configuração de confiança formatado em JSON (tc.json) que criou anteriormente. Se as suas cargas de trabalho forem autenticadas em diferentes domínios de confiança, tem de especificar este ficheiro. Caso contrário, pode omitir --inline-trust-config.

Verifique se o Workload Identity Pool foi atualizado

Para verificar se o Workload Identity Pool foi atualizado juntamente com a configuração de emissão de certificados e a configuração de confiança, execute o seguinte comando:

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

Substitua TRUST_DOMAIN_NAME pelo nome do domínio fidedigno que usou para atualizar o conjunto de identidades da carga de trabalho anteriormente neste documento.

O resultado do comando tem um aspeto semelhante ao seguinte:

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
inlineTrustConfig:
    additionalTrustBundles:
      example.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL1
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL2
            -----END CERTIFICATE-----
      myorg.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL3
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL4
            -----END CERTIFICATE-----
name: PROJECT_ID.svc.id.goog
state: ACTIVE

Se inlineCertificateIssuanceConfig ou inlineTrustConfig não estiver presente no resultado do comando, verifique se configurou corretamente a CLI gcloud para usar o projeto correto para faturação e quota. Pode ter de atualizar para uma versão mais recente da CLI gcloud.

Autorize identidades de cargas de trabalho geridas a pedir certificados ao conjunto da AC

Depois de associar as ACs ao Workload Identity Pool, tem de autorizar as identidades de carga de trabalho geridas a pedir certificados ao conjunto de ACs. Para autorizar estas identidades, faça o seguinte:

Conceda a função IAM CA Service Workload Certificate Requester (roles/privateca.workloadCertificateRequester) em cada conjunto de ACs subordinadas ao domínio de confiança. O seguinte comando gcloud privateca pools add-iam-policy-binding autoriza o domínio fidedigno a pedir certificados às cadeias de certificados do serviço de AC.
```
gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.workloadCertificateRequester \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID
```
Substitua o seguinte:
- SUBORDINATE_CA_POOL_ID: o ID do conjunto de ACs subordinadas.
- REGION: a região do conjunto de ACs subordinadas.
- PROJECT_NUMBER: o número do projeto do projeto que contém o Workload Identity Pool do GKE.
  
  Para obter PROJECT_NUMBER de PROJECT_ID, execute o seguinte comando:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
- PROJECT_ID: o ID do projeto do projeto anfitrião do conjunto de dispositivos do GKE.
- CA_PROJECT_ID: o ID do projeto no qual criou a CA subordinada.
Conceda a função Leitor do pool do serviço de AC (roles/privateca.poolReader) aos pools de AC subordinados à identidade da carga de trabalho gerida. Ao fazê-lo, autoriza a identidade da carga de trabalho gerida a obter os certificados X.509 assinados das cadeias de certificados da AC.
```
gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.poolReader \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID
```
Substitua o seguinte:
- SUBORDINATE_CA_POOL_ID: o ID do conjunto de ACs subordinadas.
- REGION: a região do conjunto de ACs subordinadas.
- PROJECT_NUMBER: o número do projeto do projeto que contém o Workload Identity Pool do GKE.
- PROJECT_ID: o ID do projeto do projeto anfitrião do conjunto de dispositivos do GKE.
- CA_PROJECT_ID: o ID do projeto no qual criou a CA subordinada.

Implemente cargas de trabalho com identidades de cargas de trabalho geridas

Depois de configurar os conjuntos de ACs para emitir certificados para identidades de carga de trabalho geridas, pode implementar cargas de trabalho que tenham identidades de carga de trabalho geridas.

Esta secção mostra como implementar uma carga de trabalho de teste que tenha uma identidade da carga de trabalho gerida. Para o fazer, implemente um pod, verifique se foram geradas credenciais e veja o certificado e o ID SPIFFE.

Implemente um pod

Para implementar um pod de teste no cluster, faça o seguinte:

Obtenha as credenciais do cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

Crie o espaço de nomes do Kubernetes.

kubectl create namespace KUBERNETES_NAMESPACE

Implemente um PodSpec de teste.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/svc.id.goog
EOF

Apresente as credenciais da carga de trabalho

Para apresentar uma lista das credenciais da carga de trabalho, execute o seguinte comando. A criação das credenciais pode demorar alguns minutos.

kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls  /var/run/secrets/workload-spiffe-credentials

Deverá ver o seguinte resultado:

ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json

Veja o certificado

Para ver o certificado, faça o seguinte:

Exporte o certificado para um ficheiro de certificado.

kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile

Veja o ficheiro de certificado.
```
cat certfile
```
No certificado, no atributo X509v3 Subject Alternative Name, vê o ID SPIFFE no seguinte formato: spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

default refere-se à ServiceAccount do Kubernetes predefinida.

Teste a autenticação de carga de trabalho para carga de trabalho

Para testar a autenticação de carga de trabalho para carga de trabalho, consulte o artigo Teste a autenticação mTLS com o Go.

O exemplo de código no repositório cria cargas de trabalho de cliente e servidor. Pode testar a autenticação mútua entre as cargas de trabalho através dos certificados que gerou anteriormente neste documento.

O que se segue?

Resolva problemas do Workload Identity gerido para o GKE.
Saiba mais acerca da criação de conjuntos de ACs.