Casos de uso de políticas personalizadas
Uso de uma política personalizada junto com políticas definidas pelo sistema com permissão completa
Se quiser atribuir permissões completas a um usuário, mas não permitir que ele acesse um serviço específico, como o Cloud Trace Service (CTS), crie uma política personalizada para negar acesso ao CTS e anexe essa política personalizada junto com a política FullAccess ao usuário. Como uma negação explícita em qualquer política substitui qualquer permissão, o usuário pode executar operações em todos os serviços, exceto CTS.
Exemplo de política que nega acesso apenas ao CTS:
{
"Version": "1.1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"cts:*:*"
]
}
]
}
- Action: operações a serem realizadas. Cada ação deve ser definida no formato "Service name:Resource type:Operation".
Por exemplo, cts:*:* refere-se a permissões para executar todas as operações em todos os tipos de recursos de CTS.
- Effect: determina se deve negar ou permitir a operação.
Uso de uma política personalizada junto com uma política definida pelo sistema
- Se você quiser atribuir permissões completas a um usuário, mas não permitir que ele crie BMSs, crie uma política personalizada negando a ação bms:servers:create e anexe essa política personalizada junto com a política BMS FullAccess ao usuário. Como uma negação explícita em qualquer política substitui qualquer permissão, o usuário pode executar todas as operações no BMS, exceto a criação de BMSs.
Exemplo de política que nega a criação de BMS:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "bms:servers:create" ] } ] }
- Se você deseja atribuir permissões somente leitura do OBS a todos os usuários, mas impedir que determinados usuários visualizem recursos específicos, por exemplo, proibir usuários cujos nomes começam com TestUser de visualizar buckets cujos nomes começam com TestBucket, crie uma política personalizada negando tais operações e anexe esta política personalizada junto com a política OBS ReadOnlyAccess para esses usuários. Como uma negação explícita em qualquer política substitui qualquer permissão, certos usuários não podem ver buckets cujos nomes começam com TestBucket.
Exemplo de política que nega aos usuários cujos nomes começam com TestUser a visualização de buckets cujos nomes começam com TestBucket:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "obs:bucket:ListAllMybuckets", "obs:bucket:HeadBucket", "obs:bucket:ListBucket", "obs:bucket:GetBucketLocation" ], "Resource": [ "obs:*:*:bucket:TestBucket*" ], "Condition": { "StringStartWith": { "g:UserName": [ "TestUser" ] } } } ] }
Atualmente, apenas alguns serviços de nuvem (como o OBS) suportam autorização baseada em recursos. Para serviços que não suportam esta função, não é possível criar políticas personalizadas que contenham tipos de recursos.
Uso de apenas uma política personalizada
Você pode criar uma política personalizada e anexar apenas a política personalizada ao grupo ao qual o usuário pertence.
- A seguir está um exemplo de política que permite acesso apenas ao ECS, EVS, VPC, ELB e Application Operations Management (AOM).
{ "Version": "1.1", "Statement": [ { "Effect": "Allow" "Action": [ "ecs:*:*", "evs:*:*", "vpc:*:*", "elb:*:*", "aom:*:*" ] } ] }
- Veja a seguir um exemplo de política que permite que apenas usuários do IAM cujos nomes começam com TestUser excluam todos os objetos no diretório my-object do bucket my-bucket.
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "obs:object:DeleteObject" ], "Resource": [ "obs:*:*:object:my-bucket/my-object/*" ], "Condition": { "StringStartWith": { "g:UserName": [ "TestUser" ] } ] } - Veja a seguir um exemplo de política que permite acesso a todos os serviços, exceto ECS, EVS, VPC, ELB, AOM e APM.
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "*:*:*" ] }, { "Action": [ "ecs:*:*", "evs:*:*", "vpc:*:*", "elb:*:*", "aom:*:*", "apm:*:*" ], "Effect": "Deny" } ] }
