Skip to main content
Cada endpoint de computação verifica uma ação do IAM antes de fazer qualquer coisa, com uma exceção observada abaixo.
A referência da API mostra a ação na própria página de cada ponto de extremidade, para que você não precise voltar aqui para procurar uma. Ambos vêm do mesmo lugar: a chamada de autorização no serviço, lida no momento da compilação.

Recursos

Os recursos nomeados podem ser endereçados de forma legível em uma política. Por exemplo, uma instância CRN carrega seu nome imutável:
Os CRNs de instância e pool possuem nomes imutáveis. Os CRNs de imagem fixam o nome, a arquitetura e a versão. Imagens e tipos de instância de plataforma usam o identificador de conta platform.

As ações

Permissões de coleção de escopo

As ações de criação e listagem verificam um CRN de coleção digitado com a região configurada e o identificador de conta solicitante. Por exemplo, crn:compute:sa-saopaulo-1:my-account:instance/* concede a criação e a listagem de instâncias nessa região e conta; uma política que nomeia outra região ou conta não. Flavors são um catálogo global de regiões: compute:ListFlavors verifica crn:compute:<region>:platform:flavor/* usando o identificador de conta platform. Listagem de imagens e verificação de criação crn:compute:<region>:<account>:image/* usando a conta solicitante, incluindo a conta de plataforma para compute:CreateImage. A listagem pode retornar imagens de plataforma com platform em seus CRNs de objeto; esses CRNs de objeto são distintos da coleção usada para autorizar a solicitação. Subsídios existentes com "resources": ["*"] ainda funcionam. Padrões de recursos digitados em instruções de deny agora também correspondem a essas ações de coleta, e um deny explícito tem precedência sobre um allow. Essa política permite o lançamento e a listagem de instâncias em uma conta e região. Sua instrução separada limita operações em instâncias existentes por tag:
Criar ações expõe tags enviadas como basalt:RequestTag/<key>. Mantenha as condições basalt:ResourceTag/<key> em operações de recursos existentes: a instância ainda não existe durante a criação, e as verificações de lista nomeiam uma coleção.

Ler não é uma ação

Três endpoints de console exigem três ações diferentes, deliberadamente: O terceiro não é uma leitura. É um acesso interativo a uma máquina em execução, e é o que deve ser negado a qualquer pessoa que só precise diagnosticar uma inicialização.
Criar um ticket de console (POST /v1/instances/{instance_id}/console/ticket) verifica nenhuma ação do IAM. Ele requer autenticação e contexto org e nada mais, porque o ticket carrega identidade, não autorização: se o console pode realmente abrir é decidido quando o soquete se conecta, contra compute:StartSerialConsole como a política está naquele momento.Congelando a decisão no ticket significaria uma permissão revogada no minuto intermediário ainda deixar o console aberto. Um ticket para uma instância que você não pode alcançar é emitido e, em seguida, inútil.

Os sub-recursos são governados pelo seu pai

Listando NICs ou volumes de uma instância precisa de compute:GetInstance — não há nenhuma ação de leitura separada para qualquer um. O mesmo padrão abrange pools: ler os IPs flutuantes de um pool ou suas instâncias precisa de compute:GetInstancePool, e anexar um endereço, separar um ou atualizar o pool precisam de compute:UpdateInstancePool.
Isso significa que compute:UpdateInstancePool é um grant que cobre três coisas bem diferentes: redimensionar o pool, rolar cada membro em um novo template e anexar um endereço público a ele. Não há como permitir o redimensionamento e reter o rolo.

Uma ação cujo nome não corresponde à chamada

PATCH /v1/instances/{instance_id}/volumes/{volume_id} muda delete_on_termination — o sinalizador que decide se um volume sobrevive à instância sendo excluída. É autorizado por compute:AttachVolume.O registro de auditoria para ele lê compute:UpdateVolumeAttachment, que é um rótulo em vez de uma ação: nenhuma política pode concedê-lo, e procurar por ele não encontra nada.

A propriedade da imagem limita as permissões

Todas as contas usam compute:CreateImage, compute:UpdateImage e compute:DeleteImage, incluindo a conta da plataforma. Não há nenhuma ação separada CreatePlatformImage, UpdatePlatformImage ou DeletePlatformImage. Atualizar e excluir exigem que a conta selecionada seja proprietária da imagem. A visibilidade de catálogo público e as concessões de IAM de curinga não ignoram a propriedade. Uma solicitação de uma conta de cliente para alterar uma imagem de plataforma retorna 403; a imagem de outro cliente retorna 404. Selecione a conta proprietária e conceda a ação de imagem comum em seu CRN para gerenciá-la. As imagens retiradas permanecem inspecionáveis com as ações de leitura comuns. Um proprietário pode excluir um após remover referências de instância e pool. A exclusão de imagens permanece legível durante a limpeza, mas as solicitações de mutação retornam 404.

Alterar uma função de carga de trabalho de instância

Anexando, substituindo e desvinculando uma função em uma instância existente requer compute:UpdateInstance com escopo para essa instância. Anexar e substituir adicionalmente requerem iam:PassRole na função selecionada. A função deve pertencer à mesma conta e sua política de confiança deve permitir o CRN da instância. Detach não tem função de destino e não requer iam:PassRole. Consulte Alterar a função de uma instância existente para obter restrições de ciclo de vida e a validade de credenciais emitidas anteriormente.

Próximo

Escrever políticas

Condições, operadores e como deny é avaliado.

Solução de problemas

O que significa um status e por que um lançamento falhou.