Funções e credenciais

As funções e contas de serviço pertencem a uma conta. Uma conta de serviço troca sua chave de acesso por um token de portador. Um usuário confiável, conta de serviço, carga de trabalho ou sessão de função pode assumir uma função para receber credenciais temporárias para sua conta.

Contas de serviço

Teclas de acesso de longa duração para scripts e CI.

Funções

Permissões que outra coisa pega emprestado, controladas por uma política de confiança.

Credenciais temporárias

Assuma uma função, opcionalmente reduzida ainda mais.

Identidade da instância

Uma VM que obtém credenciais sem segredo para implantar.

Contas de serviço

Uma conta de serviço é uma identidade não humana que contém chaves de acesso. Crie um, dê permissões e, em seguida, crie uma credencial nele:

Console
API
CLI
Go

Vá para Identity & access → Service accounts e escolha Create Service Account. Em Service Account Details, dê um Name — letras minúsculas, números e hífens, começando com uma letra — e opcionalmente uma Description.Na própria conta de serviço, o cartão Credentials tem Create Credential: um Name e um Expires At que você pode deixar em branco para uma credencial que não expira.O segredo aparece em seguida em uma caixa de diálogo Credential Created, com Copy access key ID e Copy secret access key. Esse diálogo é o único lugar onde ele é mostrado.

POST /v1/service-accounts
{ "name": "deploy-bot" }

POST /v1/service-accounts/{service_account_id}/credentials
{ "name": "ci-key" }

basaltic iam service-account create --name deploy-bot
basaltic iam service-account create-credential <service-account-id> \
  --name ci-key

--expires-at na credencial leva um carimbo de data/hora RFC 3339.

c := iam.New(cfg)
sa, err := c.CreateServiceAccount(ctx, &iam.ServiceAccountCreateRequest{
    Name: "deploy-bot",
})
cred, err := c.CreateServiceAccountCredential(ctx, sa.ID,
    &iam.CredentialCreateRequest{Name: "ci-key"})

O segredo está nesta resposta e em nenhum outro lugar.

A resposta carrega access_key_id e secret_access_key.

O segredo é retornado uma vez, na criação, e não é armazenado em um formulário que a API possa mostrar novamente. Se você perdê-la, exclua a credencial e crie outra.

Uma conta de serviço começa sem permissões. Anexe políticas de conta diretamente; contas de serviço não se juntam a grupos. Use a tabela de política organizacional separada somente quando ela precisar de acesso da organização, como leitura do uso de faturamento.

Console
API
CLI
Go

Na guia Policies da conta de serviço, escolha Attach account policy em Account policies. As concessões de organização usam Attach organization policy na tabela separada Organization policies.

POST https://iam.basaltic.sh/v1/service-accounts/{service_account_id}/policies
{ "policy": "<account-policy>" }

As concessões de organização usam o mesmo caminho em workspace.basaltic.sh, com { "policy_id": "<organization-policy-uuid>" }.

basaltic iam service-account attach-policy <service-account-id> \
  --policy <policy-id>

err := iam.New(cfg).AttachServiceAccountPolicy(ctx, serviceAccountID,
    &iam.PolicyAttachRequest{Policy: policyID})

A delegação de organização requer autoridade em ambos os escopo. Consulte Permissões de espaço de trabalho.

Funções

Uma função é um conjunto de permissões com sem credenciais próprias. Algo mais assume e obtém credenciais temporárias que autorizam como a função. Uma função tem duas metades:

Políticas de permissão

O que a função pode fazer em sua conta, além de quaisquer políticas de organização delegadas separadamente.

Política de confiança

Quem tem permissão para assumi-lo. Sem isso, ninguém pode.

No console, abra Identity & access → Funções → Criar função. O editor Trust Policy suporta edição visual e JSON. Uma função salva tem tabelas separadas de Account policies e Organization policies.

Políticas de confiança

A política de confiança lista padrões de CRN correspondentes ao CRN do próprio chamador:

{
  "principals": [
    "crn:iam::automation:service-account/deploy-bot",
    "crn:compute:*:my-account:instance/*"
  ],
  "conditions": [
    { "operator": "ip_address", "key": "basalt:SourceIp", "values": ["10.0.0.0/8"] }
  ]
}

principals portas quem; conditions portas sob que circunstâncias. Ambos devem resistir. Principais de conta de função e serviço incluem seu identificador de conta proprietário. Quando você salva um principal do IAM nomeado concreto, ele é vinculado ao UUID imutável dessa identidade. Excluir uma identidade e recriar seu nome não herda sua confiança. A confiança humana aceita um nome de usuário específico ou crn:workspace:::user/* para todos os usuários na organização selecionada. IDs de usuário numéricos permanecem válidos durante a seleção inicial do nome de usuário.

Chamador de telefone	Principal CRN
Conta de serviço	`crn:iam::<account-handle>:service-account/<service-account-uuid>`
Papel assumido	`crn:iam::<account-handle>:role/<role-uuid>`
Usuário registrado	`crn:workspace:::user/<username>`
Compute instância	`crn:compute:<region>:<account-handle>:instance/<instance-id>`

Os grupos não são os principais que podem assumir um papel. Use a confiança do usuário junto com uma atribuição de função de grupo. A confiança só se aplica dentro da organização da função; a assunção de função entre organizações não é suportada.

* é o único curinga e o layout de dois pontos/barra é comparado literalmente. Um padrão escrito em qualquer outra forma não corresponde a nada — ele não falha alto, ele simplesmente nunca corresponde, então verifique a forma quando uma política de confiança parece ser ignorada.

Assumindo um papel

AssumeRole tem dois portões independentes: a fonte deve ser permitida para executar iam:AssumeRole na função de destino, e a política de confiança do destino deve aceitar a fonte. Para os seres humanos, uma atribuição de função de conta fornece a fonte de permissão. Para contas de serviço e sessões de função, conceda a ação de origem em uma política de conta. Use o CRN de função completo da conta de destino para acesso entre contas dentro da sua organização. Uma política de origem pode nomear essa função, mesmo que esteja em uma conta diferente. Alterar X-Account-Id sozinho nunca concede esse acesso. O console assume automaticamente sua função atribuída única quando você seleciona uma conta. As atribuições diretas e de grupo podem conceder a mesma função; funções distintas conflitantes em uma conta são rejeitadas. Para integrações, o POST /v1/assume-role do IAM aceita role, opcional duration_seconds e uma sessão opcional policy. Use um CRN de função qualificado, como crn:iam::production:role/deploy. A resposta inclui access_token, expiration, account_id, account_handle, e role_id. Verifique a vinculação de destino antes de usar Authorization: Bearer <access_token> para solicitações de API de conta. Os atributos access_key_id, secret_access_key e session_token são para a versão 4 da assinatura S3. Veja autenticação. A sessão de função autoriza como a função de destino. Ele não herda ou união as permissões do principal de origem.

900–43200, default 3600

15 minutos a 12 horas, também delimitado pela duração máxima da sessão da função.

Reduzir o escopo de uma sessão

policy na chamada assume-role anexa uma política de sessão às credenciais que estão sendo criadas:

{
  "role": "crn:iam::production:role/deploy",
  "policy": {
    "version": "2024-01-01",
    "statements": [{
      "effect": "allow",
      "actions": ["storage:GetObject"],
      "resources": ["crn:storage:sa-saopaulo-1:my-account:bucket/reports/*"]
    }]
  }
}

Uma política de sessão não concede nada. Cada solicitação feita com as credenciais resultantes deve ser permitida pelas próprias políticas da função e pela política de sessão. É um cruzamento, por isso só pode estreitar.As declarações de política de sessão assumem a mesma forma de uma política gerenciada, mas carregam sem condições — uma política de sessão restringe somente ações e recursos.

Uma política de sessão inválida falha a chamada com INVALID_INPUT em vez de ser ignorada.

Assistindo a sessões

Abra Identity & access → Sessões STS para a conta selecionada. As sessões mostram a conta e a função de destino, a expiração, o tipo de concessão e a proveniência do principal de origem. Sessões mais antigas podem ter campos de origem ausentes. Os endpoints correspondentes do IAM são GET /v1/sts-sessions, GET /v1/sts-sessions/{session_id} e DELETE /v1/sts-sessions/{session_id}. Excluir uma sessão a revoga. A autorização re-verifica a expiração e a revogação. As sessões de início de sessão pessoal são geridas através de pontos finais de autenticação, não desta lista de recursos de conta.

Dar uma identidade a uma instância

A função e a instância devem pertencer à mesma conta. O chamador que anexa-lo precisa iam:PassRole, bem como a ação compute. Se a função tiver concessão de políticas da organização, a aprovação também exigirá autoridade de delegação da organização; a administração da conta sozinha não pode transferir essas concessões. Essa é a razão pela qual as funções valem a pena a configuração: uma instância pode conter credenciais sem que nenhum segredo seja implantado nela.

Escrever uma política de confiança que aceita instâncias

{ "principals": ["crn:compute:*:my-account:instance/*"] }

Restringa-o a um id de instância específico, se possível.

Anexar políticas de permissão à função

Tudo o que a carga de trabalho realmente precisa — e nada mais, já que qualquer coisa em execução na instância pode acessar essas credenciais.

Inicie a instância com a função

Console
API
CLI
Go

Em Compute → Instances → Create instance, o cartão IAM role tem uma seleção Role. O padrão é No role.

POST /v1/instances
{ "name": "web-1", "iam_role": "7c9e6679-7425-40de-944b-e07fc1f90ae7", ... }

basaltic compute instance create --name web-01 \
  --flavor s1.small --image debian-13 \
  --iam-role crn:iam::my-account:role/web \
  --networks '[{"subnet":"c1d2e3f4-a5b6-4c7d-8e9f-0a1b2c3d4e5f"}]'

_, err := compute.New(cfg).CreateInstance(ctx, &compute.InstanceCreateRequest{
    Name: "web-01", Flavor: "s1.small",
    Image: basaltic.String("debian-13"),
    IAMRole: basaltic.String("crn:iam::my-account:role/web"),
    Networks: []*compute.NetworkConfig{{Subnet: subnetID}},
})

Leia credenciais de dentro da VM

O serviço de metadados de instância em 169.254.169.254 mints e serve credenciais temporárias para a função anexada. Eles rodam antes de expirarem, então um processo que os releia continua funcionando indefinidamente.

Nada de secreto é escrito na instância. O serviço de metadados identifica o chamador por qual instância ele é, cria uma sessão contra a função anexada e entrega credenciais que expiram por conta própria.

A política de confiança da função deve permitir crn:compute:*:*:instance/*, ou o CRN da instância específica. Uma instância iniciada com iam_role definido, mas uma política de confiança que não o aceita não obtém credenciais.

Qual identidade usar

Pipeline de CI

Uma conta de serviço com uma chave de acesso, armazenada no armazenamento secreto da CI. Escolha o escopo para a conta e as ações que o pipeline precisa. Se o pipeline fizer várias coisas não relacionadas, prefira várias contas de serviço em vez de uma chave ampla.

Software em execução em uma instância

Uma função de instância. Nenhum segredo é implantado, as credenciais são rotacionadas por conta própria e a revogação do acesso é uma alteração na função, e não uma reimplantação.

Uma pessoa fazendo trabalho operacional

O login pessoal e uma função de conta atribuída. Use credenciais de função temporárias para operações de conta; mantenha o trabalho da organização em sua sessão pessoal do Workspace.

Concessão de acesso elevado temporário

Um papel com uma política de confiança e permissão de origem ou atribuição humana, além de um curto duration_seconds. A suposição é gravada como uma sessão STS, de modo que a elevação é visível e revogável em vez de implícita.

Escrever políticas

O que colocar nas políticas de permissão de uma função.

Limites de permissão

O limite de uma função também limita suas sessões.

Primeiros passos

Produtos

Plataforma

Ajuda

Funções e credenciais

Contas de serviço

Funções

Credenciais temporárias

Identidade da instância

Contas de serviço

Funções

Políticas de permissão

Política de confiança

Políticas de confiança

Assumindo um papel

Reduzir o escopo de uma sessão

Assistindo a sessões

Dar uma identidade a uma instância

Qual identidade usar

Próximo

Escrever políticas

Limites de permissão

Contas de serviço

Funções

Credenciais temporárias

Identidade da instância

​Contas de serviço

​Funções

Políticas de permissão

Política de confiança

​Políticas de confiança

​Assumindo um papel

​Reduzir o escopo de uma sessão

​Assistindo a sessões

​Dar uma identidade a uma instância

​Qual identidade usar

​Próximo

Escrever políticas

Limites de permissão

Contas de serviço

Funções

Políticas de confiança

Assumindo um papel

Reduzir o escopo de uma sessão

Assistindo a sessões

Dar uma identidade a uma instância

Qual identidade usar

Próximo