Uma prova de identidade e um token de acesso à API têm finalidades diferentes. O JWT OIDC comprova a identidade durante a troca. As credenciais resultantes autorizam requisições de acordo com as permissões da role no destino. Os tokens bearer da API Basaltic usam uma chave de assinatura separada e não substituem os tokens de identidade de VM.
Gerar um token pela API
Uma service account autenticada ou uma sessão de role assumida pode chamarGetWebIdentityToken. Usuários humanos primeiro assumem uma role da conta. A conta selecionada deve corresponder ao workload autenticado. Os metadados continuam disponíveis para a VM obter sua prova diretamente.
Conceda iam:GetWebIdentityToken no CRN da própria role ou service account do chamador. Restrinja basalt:IdentityTokenAudience ao destino. Por exemplo:
BASALTIC_TOKEN. Mantenha a resposta privada:
token e expires_at. A duração padrão é de 300 segundos; valores explícitos vão de 60 a 300. A sessão de origem deve continuar válida por esse período. basalt:IdentityTokenDurationSeconds pode restringi-lo ainda mais. Renove chamando o endpoint novamente.
O sujeito é derivado da identidade autenticada. Nomes, sujeitos escolhidos pelo chamador e claims JWT arbitrários não são aceitos:
Escolher a audiência de destino
Aaudience é escolhida para a plataforma de destino, não é fixa para AWS. Use o valor esperado pela plataforma e configure permissões de emissão e confiança correspondentes. Os exemplos AWS usam sts.amazonaws.com; outro serviço pode exigir uma URL, identificador de cliente ou URN. A audiência basaltic é reservada para tokens da API Basaltic.
O claim JWT é aud. A forma iam.basaltic.sh:aud é uma chave de condição de confiança AWS que referencia esse claim. Outras plataformas usam sua própria configuração de mapeamento de claims. Elas precisam aceitar JWTs externos de workloads e as assinaturas ES256 do Basaltic; apenas uma integração de login OIDC interativo não basta.
Aceitar uma identidade externa
Três verificações independentes precisam passar:- Registre o emissor na mesma conta da role de destino, com as audiências aceitas pela conta.
- Adicione o CRN do provedor à política de confiança da role e restrinja o sujeito.
- Anexe à role as políticas de permissão para as operações necessárias ao workload.
Restringir a confiança
Sempre vincule a confiança ao sujeito desejado. Use também uma condição de audiência quando o provedor aceitar várias audiências, mas a role deva aceitar apenas uma.Subject é uma string. Audience é um conjunto, mesmo quando o JWT contém uma só audiência: sua condição precisa de set_operator: "for_any_value" para verificar pertinência. Uma condição escalar equals em Audience não corresponde a esse conjunto.
Provedores genéricos de clientes disponibilizam o emissor, o sujeito e a audiência verificados para avaliar a confiança. Claims personalizados arbitrários do JWT não estão disponíveis como chaves de política. Não presuma que um claim de instância EC2, um rótulo de job de CI ou outro campo personalizado restrinja a confiança, a menos que o próprio sujeito compatível forneça essa restrição.
Para GitHub Actions, use o sujeito exato emitido para o workflow, incluindo os IDs imutáveis do proprietário e do repositório quando presentes. Restrinja a organização ou o repositório e a branch ou o ambiente desejado. Provedores GitHub exigem uma restrição positiva de organização ou repositório no sujeito. O nome da sessão é um rótulo de auditoria; ele não altera o sujeito verificado.
Trocar a prova
Envie o JWT e o CRN completo da role de destino ao endpoint público de IAM. A troca usa o próprio JWT e não exige uma chave de acesso ou token bearer Basaltic existente.account na requisição. A resposta contém credenciais temporárias de chave de acesso e um token bearer. Use o bearer nas APIs Basaltic e as credenciais temporárias no endpoint compatível com S3. Consulte autenticação.
Sessões de role Basaltic duram uma hora por padrão. Uma duração explícita deve ser de pelo menos 900 segundos e respeitar o máximo configurado na role, até 12 horas. A expiração da prova determina até quando ela pode ser trocada; não encurta uma sessão já emitida.
Renovação e revogação
Obtenha uma nova prova de identidade do emissor e troque-a antes de a sessão Basaltic expirar. Essa troca não possui refresh token OIDC. Atualizar as audiências de um provedor ou excluí-lo impede novas trocas que deixem de atender ao registro. Alterar a confiança da role afeta novas trocas. Sessões existentes permanecem válidas até expirarem ou serem revogadas. Revogue uma sessão para encerrar seu bearer e suas credenciais temporárias. Recriar um provedor com o mesmo nome não restaura o vínculo de confiança anterior; atualize a política da role para autorizar o novo provedor. Provedores marcados comois_system são gerenciados pela plataforma e não podem ser alterados nem excluídos. Workloads de clientes devem registrar seu próprio emissor acessível publicamente.
Descoberta e chaves
O Basaltic publica dois documentos de metadados com finalidades diferentes:
Descubra e armazene em cache o JWKS adequado; não fixe uma única chave de assinatura. Durante a rotação, várias chaves públicas podem ser publicadas. Verifique
kid, algoritmo, emissor, audiência, sujeito e expiração do JWT.