O Google Cloud Platform oferece gerenciamento de identidade e acesso (IAM) para que você possa conceder acesso mais detalhado a recursos específicos da plataforma e evitar acesso indesejado a outros recursos. Nesta página, descrevemos os papéis da API Cloud DNS. Para uma descrição detalhada do Cloud IAM, leia a documentação do IAM.
Com o IAM, é possível adotar o princípio de segurança do menor privilégio para conceder apenas o acesso necessário aos recursos.
O IAM permite que você defina políticas para controlar quem tem quais permissões em que recursos. As políticas de IAM concedem papéis específicos a um usuário, que recebe determinadas permissões. Por exemplo, um determinado usuário pode precisar criar e modificar recursos de registro DNS. Então, você daria a esse usuário (quem) o papel /roles/dns.admin, que tem as permissões dns.changes.create e dns.resourceRecordSets.create (quais), para que ele possa criar e atualizar conjuntos de registros de recurso (que). Por outro lado, um departamento de suporte pode precisar apenas visualizar conjuntos de registros de recurso atuais. Para isso, é concedido apenas o papel /roles/dns.reader.
Permissões e papéis
Todos os métodos da API Cloud DNS exigem que os autores das chamadas tenham as devidas permissões do IAM. As permissões são atribuídas por meio da atribuição de papéis a um usuário, grupo ou conta de serviço. Além dos papéis primários de proprietário, editor e visualizador, é possível atribuir papéis da API Cloud DNS aos usuários do projeto.
Permissões
A tabela a seguir lista as permissões que o solicitante precisa ter para chamar cada método:
| Método | Permissões necessárias |
|---|---|
| dns.changes.create para criar um conjunto de registros de recurso | dns.changes.create e dns.resourceRecordSets.create no projeto que contém o conjunto de registros |
| dns.changes.create para atualizar um conjunto de registros de recurso | dns.changes.create e dns.resourceRecordSets.update no projeto que contém o conjunto de registros |
| dns.changes.create para excluir um conjunto de registros de recurso | dns.changes.create e dns.resourceRecordSets.delete no projeto que contém o conjunto de registros |
| dns.changes.get | dns.changes.get para o projeto que contém a zona gerenciada |
| dns.changes.list | dns.changes.list para o projeto que contém a zona gerenciada |
| dns.dnsKeys.get | dns.dnsKeys.get para o projeto que contém a zona gerenciada |
| dns.dnsKeys.list | dns.dnsKeys.list para o projeto que contém a zona gerenciada |
| dns.managedZoneOperations.get | dns.managedZoneOperations.get para o projeto que contém a zona gerenciada |
| dns.managedZoneOperations.list | dns.managedZoneOperations.list para o projeto que contém a zona gerenciada |
| dns.managedZones.create | dns.managedZones.create para o projeto que contém a zona gerenciada Ao criar uma zona privada, você também precisará de dns.networks.bindPrivateDNSZone e dns.networks.targetWithPeeringZone para cada projeto que contém uma rede VPC autorizada a acessar a zona. |
| dns.managedZones.delete | dns.managedZones.delete para o projeto que contém a zona gerenciada |
| dns.managedZones.get | dns.managedZones.get para o projeto que contém a zona gerenciada |
| dns.managedZones.list | dns.managedZones.list para o projeto que contém a zona gerenciada |
| dns.managedZones.update | dns.managedZones.update para o projeto que contém a zona gerenciada Ao criar uma zona privada, você também precisará de dns.networks.bindPrivateDNSZone e dns.networks.targetWithPeeringZone para cada projeto que contém uma rede VPC autorizada a acessar a zona. |
| dns.policies.create | dns.policies.create para o projeto que contém a política.
Se a política for criada em uma rede VPC, você também precisará de dns.networks.bindPrivateDNSPolicy para cada projeto que contém uma rede VPC. |
| dns.policies.delete | dns.policies.delete para o projeto que contém a política |
| dns.policies.get | dns.policies.get para o projeto que contém a política |
| dns.policies.list | dns.policies.list para o projeto que contém a política |
| dns.policies.update | dns.policies.update para o projeto que contém a política.
Se a política for atualizada para estar em uma rede VPC, você também precisará de dns.networks.bindPrivateDNSPolicy para cada projeto que contém uma rede VPC. |
| dns.policies.patch | dns.policies.patch para o projeto que contém a política |
| dns.projects.get | dns.projects.get para o projeto |
| dns.resourceRecordSets.list | dns.resourceRecordSets.list para o projeto que contém a zona gerenciada |
Papéis
Veja na tabela abaixo os papéis do IAM da API do Cloud DNS com uma lista correspondente de todas as permissões que cada um deles inclui. Cada permissão se aplica a um tipo específico de recurso.
Os papéis primários também podem ser usados para fazer alterações no DNS.
| Papel | Nome | Descrição | Permissões | Menor recurso |
|---|---|---|---|---|
roles/ |
Administrador do DNS | Dá acesso de leitura e gravação a todos os recursos do Cloud DNS. |
|
Projeto |
roles/ |
Par do DNS | Acesso às redes de destino com zonas DNS de peering |
|
|
roles/ |
Leitor do DNS | Dá acesso somente leitura a todos os recursos do Cloud DNS. |
|
Projeto |
Controle de acesso por meio do Console do Cloud
É possível usar o Console do Cloud para gerenciar o controle de acesso dos seus tópicos e projetos.
Para definir os controles de acesso no nível do projeto:
- Abra a página "IAM" no Console do Google Cloud.
- Selecione seu projeto no menu suspenso na parte superior.
- clique em Adicionar;
- digite o endereço de e-mail de um novo membro;
- Selecione o papel desejado no menu suspenso;
- Clique em Adicionar;
- verifique se o membro está listado com o papel concedido.
A seguir
- Para começar a usar o Cloud DNS, consulte o Início rápido.
- Consulte a documentação do IAM para ver detalhes sobre o gerenciamento de identidade e acesso.