> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Funções e credenciais > Chaves de acesso, funções e políticas de confiança, credenciais temporárias e atribuição de uma identidade a uma instância. 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. Teclas de acesso de longa duração para scripts e CI. Permissões que outra coisa pega emprestado, controladas por uma política de confiança. Assuma uma função, opcionalmente reduzida ainda mais. 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: 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. ```bash theme={null} POST /v1/service-accounts { "name": "deploy-bot" } POST /v1/service-accounts/{service_account_id}/credentials { "name": "ci-key" } ``` ```bash theme={null} basaltic iam service-account create --name deploy-bot basaltic iam service-account create-credential \ --name ci-key ``` `--expires-at` na credencial leva um carimbo de data/hora RFC 3339. ```go theme={null} 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. 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**. ```bash theme={null} POST https://iam.basaltic.sh/v1/service-accounts/{service_account_id}/policies { "policy": "" } ``` As concessões de organização usam o mesmo caminho em `workspace.basaltic.sh`, com `{ "policy_id": "" }`. ```bash theme={null} basaltic iam service-account attach-policy \ --policy ``` ```go theme={null} 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](/pt/workspace/permissions#delegating-organization-policies). ## 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: O que a função pode fazer em sua conta, além de quaisquer políticas de organização delegadas separadamente. 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**: ```json theme={null} { "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:::service-account/` | | Papel assumido | `crn:iam:::role/` | | Usuário registrado | `crn:workspace:::user/` | | Compute instância | `crn:compute:::instance/` | 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 ` 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](/pt/authentication). 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. 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: ```json theme={null} { "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. ```json theme={null} { "principals": ["crn:compute:*:my-account:instance/*"] } ``` Restringa-o a um id de instância específico, se possível. 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. Em **Compute → Instances → Create instance**, o cartão **IAM role** tem uma seleção **Role**. O padrão é **No role**. ```bash theme={null} POST /v1/instances { "name": "web-1", "iam_role": "7c9e6679-7425-40de-944b-e07fc1f90ae7", ... } ``` ```bash theme={null} 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"}]' ``` ```go theme={null} _, 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}}, }) ``` 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 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. 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. 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. 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.