Noções básicas sobre avaliação de hierarquia e políticas

Uma política da organização define as restrições de configuração para um recurso. As políticas da organização são herdadas da hierarquia do recurso e podem ser aumentadas ou modificadas em qualquer nível em que é possível defini-las.

O diagrama abaixo mostra que ao definir as políticas da organização no nível da organização, elas são repassadas para os demais níveis do projeto. Uma política também pode ser aplicada diretamente a um projeto. O resultado efetivo em um dado recurso é determinado pelo modo como a política é definida ao longo de vários pontos na hierarquia, conforme descrito abaixo em Avaliação hierárquica.

Hierarquia de políticas

Tipos de políticas da organização

Assim como há restrições de lista e restrições booleanas, há dois tipos correspondentes de políticas da organização: políticas de lista e booleanas. As políticas de lista só podem ser definidas para restrições de lista, e as políticas booleanas só para restrições booleanas. Também há uma mensagem RestoreDefault que pode ser utilizada em uma política que substitua a política herdada pelo padrão de restrição.

Políticas de lista

Ao usar uma política de lista, é possível definir os valores específicos que são permitidos ou negados para um determinado aspecto de serviço. Ela também pode ser usada para permitir ou negar todos os valores que um serviço define para o aspecto. Use a mensagem ListPolicy para configurar como a política será aplicada nas restrições de lista.

Se você quiser permitir um grupo específico de valores, será necessário definir ListPolicy.allowed_values para as strings a serem permitidas, e ListPolicy.all_values para ALL_VALUES_UNSPECIFIED. Da mesma forma, se você precisar especificar um grupo de valores bloqueados, transmita as strings que você quer negar ao definir ListPolicy.denied_values, e defina ListPolicy.all_values como ALL_VALUES_UNSPECIFIED.

Se você simplesmente quiser permitir ou bloquear todos os valores válidos para o aspecto de serviço mapeado para a restrição, basta definir ListPolicy.all_values para ALLOW ou DENY. Observe que, se você usar uma dessas configurações, não poderá definir as propriedades ListPolicy.denied_values ou ListPolicy.allowed_values.

Em qualquer ponto de atribuição da política, o Administrador da política da organização está liberado para usar o valor allowed ou denied independentemente dos tipos de valores usados nas políticas acima ou abaixo na hierarquia. Discutimos a avaliação das políticas dentro da hierarquia em detalhes na seção abaixo.

Políticas booleanas

As políticas booleanas correspondem às restrições booleanas que são usadas para ativar ou desativar um determinado aspecto do serviço. Basta definir Policy.enforced como igual a True para aplicar a restrição.

Avaliação hierárquica

Por padrão, uma política que você definir em um recurso substitui qualquer conjunto de políticas em qualquer lugar acima dela na hierarquia de recursos. No entanto, para uma restrição de lista, se inherit_from_parent estiver definido como true, os valores da política do recurso pai serão herdados. Isso significa que os valores definidos na política são efetivamente adicionados aos valores que vieram de mais acima na hierarquia.

Na maioria das circunstâncias, não é recomendado definir hierarquias de políticas que herdam valores permitidos e negados, pois a ideia é manter a configuração simples e compreensível. No entanto, é possível definir uma política que tenha allowed_values definido e herde uma política que tenha denied_values definido. Nesse caso, os valores em allowed_values não podem estar presentes em denied_values.

Por exemplo, suponha que você tenha uma restrição de lista constraints/serviceuser.services. Essa restrição especifica a lista de serviços que são permitidos. O padrão para a restrição é definido como ALLOW.

Suponha ainda que uma política derivada dessa restrição tenha sido aplicada ao nível da organização. A política restringe as ativações de serviço permitidas a {compute.googleapis.com, datastore.googleapis.com}. Se uma política for aplicada a um projeto na organização, ao especificar que inherit_from_parent é false e definir all_values como DENY, qualquer tentativa de ativar as APIs compute.googleapis.com e datastore.googleapis.com (ou qualquer outra API) será negada.

Ver alguns exemplos de avaliação hierárquica de políticas pode tornar o assunto mais claro.

Exemplos de avaliação hierárquica

Os exemplos a seguir demonstram diferentes hierarquias possíveis e como as políticas são avaliadas.

Projeto sem valores herdados

Em nosso primeiro exemplo, vamos ver para um caso em que não há valores herdados. A organização tem uma política com valores:

{
  allowed_values: "compute.googleapis.com"
  allowed_values: "datastore.googleapis.com"
}

Um projeto nessa organização tem os valores:

{
  allowed_values: "dns.googleapis.com"
  allowed_values: "endpoints.googleapis.com"
  inherit_from_parent: false
}

Nesse caso, os valores aceitos no nível da organização são compute.googleapis.com, datastore.googleapis.com. Os valores aceitos no nível do projeto são dns.googleapis.com e endpoints.googleapis.com porque o projeto está configurado para não herdar do pai.

Projeto com valores herdados

Agora vamos ver o segundo exemplo, no qual um projeto herda valores.

Como no exemplo anterior, a organização tem uma política com os valores:

{
  allowed_values: "compute.googleapis.com"
  allowed_values: "datastore.googleapis.com"
}

E o projeto tem os mesmos valores que antes, exceto que, agora, herdar valores é definido como true:

{
  allowed_values: "dns.googleapis.com"
  allowed_values: "endpoints.googleapis.com"
  inherit_from_parent: true
}

Nesse caso, os valores aceitos na organização são compute.googleapis.com, datastore.googleapis.com. Os valores aceitos no projeto são compute.googleapis.com, datastore.googleapis.com, dns.googleapis.com e endpoints.googleapis.com porque o projeto está configurado para herdar do pai.

Herança com valores permitidos e negados

Agora, vamos examinar um caso um pouco mais interessante, no qual um projeto herda valores permitidos e nega um dos valores herdados.

Novamente, nossa organização tem uma política com valores:

{
  allowed_values: "compute.googleapis.com"
  allowed_values: "datastore.googleapis.com"
}

O projeto tem uma política aplicada que nega um dos valores permitidos no nível da organização:

{
  denied_values: "compute.googleapis.com"
}

Os valores aceitos na organização são compute.googleapis.com, datastore.googleapis.com. O único valor aceito no projeto é datastore.googleapis.com.

Como redefinir com RestoreDefault

RestoreDefault permite redefinir uma política para a configuração padrão da restrição.

Por exemplo, se a organização tiver uma política com os valores:

 {
   allowed_values: "compute.googleapis.com"
   allowed_values: "datastore.googleapis.com"
 }

E o projeto tiver uma política com valores:

 {
   RestoreDefault: {}
 }

O resultado é que os valores aceitos na organização são compute.googleapis.com e datastore.googleapis.com, e os valores aceitos no projeto são todos ou nenhum, dependendo do valor padrão da restrição. Se a restrição padrão for ALLOW, todos os valores serão permitidos. Se o padrão for DENY, nenhum dos valores será permitido.

Projeto sem política

Se um projeto não tiver nenhuma política, ele herdará a política pai.

Portanto, se a organização e o projeto não tiverem um conjunto de políticas, os valores aceitos em ambos os níveis dependerão do padrão da restrição. Se o padrão da restrição for ALLOW, todos os valores serão permitidos, e se ele for DENY, nenhum será permitido.

Se a organização tiver um conjunto de políticas, qualquer projeto abaixo dele que não tiver um conjunto herdará a política da organização.

Modificar restrição com ALLOW/DENY universal

Outro exemplo é quando você tem uma restrição de lista que permite todos os valores aplicados a um projeto que tem uma política de nível de organização com valores restritos.

Aqui, a organização tem uma política com os valores:

 {
   allowed_values: "compute.googleapis.com"
   allowed_values: "datastore.googleapis.com"
 }

E o projeto tem uma política com:

 {
   all: ALLOW
 }

Nesse caso, os valores aceitos na organização ficam restritos a compute.googleapis.com e datastore.googleapis.com, mas qualquer valor é aceito no projeto. Ou seja, a política de nível de projeto substitui a política da organização.

Da mesma forma, como você poderia esperar, um projeto pode bloquear qualquer valor permitido no nível da organização. Assim, mesmo se a organização tiver uma política com valores:

 {
   allowed_values: "compute.googleapis.com"
   allowed_values: "datastore.googleapis.com"
 }

O projeto pode definir uma política com:

 {
   all: DENY
 }

O resultado é que os valores aceitos na organização são compute.googleapis.com e datastore.googleapis.com, enquanto nenhum valor é aceito no nível do projeto.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Resource Manager