Casos de uso de políticas personalizadas
Uso de una política personalizada junto con políticas definidas por el sistema de permiso completo
Si desea asignar permisos completos a un usuario pero no permitirle acceder a un servicio específico, como Cloud Trace Service (CTS), cree una política personalizada para denegar el acceso a CTS y, a continuación, adjunte esta política personalizada junto con la política FullAccess al usuario. Como un rechazo explícito en cualquier política anula cualquier permiso, el usuario puede realizar operaciones en todos los servicios excepto CTS.
Ejemplo de política que deniega el acceso solo a CTS:
{
"Version": "1.1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"cts:*:*"
]
}
]
}
- Action: Operaciones a realizar. Cada acción debe definirse en el formato "Service name:Resource type:Operation".
Por ejemplo, cts:*:* se refiere a los permisos para realizar todas las operaciones en todos los tipos de recursos de CTS.
- Effect: determina si se debe denegar o permitir la operación.
Uso de una política personalizada junto con una política definida por el sistema
- Si desea asignar permisos completos a un usuario pero no permitirle crear BMS, cree una política personalizada que deniegue la acción bms:servers:create y, a continuación, adjunte esta política personalizada junto con la política BMS FullAccess al usuario. Como un rechazo explícito en cualquier política anula cualquier permiso, el usuario puede realizar todas las operaciones en BMS excepto crear BMS.
Ejemplo de política que deniega la creación de BMS:
{ "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "bms:servers:create" ] } ] }
- Si desea asignar permisos de solo lectura de OBS a todos los usuarios pero no permitir que ciertos usuarios vean recursos específicos, por ejemplo, no permitir que los usuarios cuyos nombres comiencen por TestUser vean depósitos cuyos nombres comiencen por TestBucket crear una política personalizada que deniegue dichas operaciones y adjuntar esta política personalizada junto con la política OBS ReadOnlyAccess a esos usuarios. Como un rechazo explícito en cualquier política anula cualquier permiso, ciertos usuarios no pueden ver depósitos cuyos nombres comienzan con TestBucket.
Política de ejemplo que niega a los usuarios cuyos nombres comienzan por TestUser ver depósitos cuyos nombres comienzan por 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" ] } } } ] }
Actualmente, solo ciertos servicios en la nube (como OBS) admiten la autorización basada en recursos. Para los servicios que no admiten esta función, no puede crear políticas personalizadas que contengan tipos de recursos.
Usar solo una política personalizada
Puede crear una política personalizada y adjuntar solo la política personalizada al grupo al que pertenece el usuario.
- A continuación se muestra una política de ejemplo que permite el acceso solo a ECS, EVS, VPC, ELB y Application Operations Management (AOM).
{ "Version": "1.1", "Statement": [ { "Effect": "Allow" "Action": [ "ecs:*:*", "evs:*:*", "vpc:*:*", "elb:*:*", "aom:*:*" ] } ] }
- A continuación se muestra una política de ejemplo que permite que solo los usuarios de IAM cuyos nombres comiencen por TestUser eliminen todos los objetos del directorio my-object del 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" ] } ] } - A continuación se muestra una política de ejemplo que permite el acceso a todos los servicios excepto ECS, EVS, VPC, ELB, AOM y APM.
{ "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "*:*:*" ] }, { "Action": [ "ecs:*:*", "evs:*:*", "vpc:*:*", "elb:*:*", "aom:*:*", "apm:*:*" ], "Effect": "Deny" } ] }
