Resumo executivo
O Okta Privileged Access (OPA) Workload Identity for Automation integra-se ao Google Cloud Platform (GCP) através da troca de JSON Web Tokens (JWTs) OIDC assinados pela plataforma por certificados SSH efêmeros e de curta duração. Uma máquina virtual executora automatizada consulta seu servidor de metadados GCP local em busca de um JWT assinado pelo Google, o envia para o OPA por meio da CLI sft para autenticação e recebe um certificado SSH baseado em tempo para acessar os servidores de destino — eliminando chaves SSH estáticas, tokens de API e arquivos JSON de contas de serviço.
Todo engenheiro de automação já passou pelo mesmo momento desconfortável: você precisa que seu script se conecte a um servidor, então você gera uma credencial, cola-a em um arquivo de configuração e segue em frente. Semanas depois, essa credencial está em três arquivos de configuração, dois pipelines de CI/CD e uma mensagem no Slack que alguém enviou para “só testar algo rapidamente”. Ninguém sabe quais ainda estão ativos. Ninguém quer ser o responsável por interromper a produção ao rotacioná-los.
Neste post do blog, apresentamos uma solução completa e funcional: usando o Okta Privileged Access (OPA) Workload Identity for Automation com o Google Cloud Platform (GCP) para permitir que um script de automação acesse um servidor de destino via Secure Shell (SSH) sem armazenar nenhuma credencial em disco.
Como as identidades de carga de trabalho do OPA e do GCP eliminam credenciais estáticas
Objetivo principal: eliminar credenciais estáticas (chaves de API, chaves SSH estáticas e arquivos JSON de contas de serviço) no acesso automatizado ao servidor, aproveitando provas de identidade assinadas pela plataforma.
Zero credenciais armazenadas: Nenhum segredo reside em disco, em configurações ou em variáveis de CI/CD.
Certificados efêmeros de curta duração: emissão de certificados SSH válidos por 15 minutos, eliminando o risco operacional de rotação.
Validação criptográfica de ponta a ponta: Okta Privileged Access, que atua como um intermediário confiável para validar JSON Web Tokens (JWTs) emitidos pelo GCP.
Registro de auditoria automatizado: rastreabilidade completa de identidade em todas as trocas de tokens e atividades de sessão SSH no Registro do Sistema Okta.
O problema: credenciais estáticas representam dívida de segurança, não recursos de infraestrutura
Quando uma tarefa automatizada — um guia prático do Ansible, um script de implantação ou um executor de CI/CD — precisa acessar um recurso privilegiado, é necessário um meio para comprovar sua identidade. A abordagem tradicional fornece uma credencial estática: uma chave de API, uma chave privada SSH ou um arquivo JSON de conta de serviço. Essa credencial fica armazenada em algum lugar, e esse lugar se torna um alvo.
As consequências se desenrolam de maneiras previsíveis:
As credenciais têm uma vida útil superior à sua finalidade: uma chave de conta de serviço criada para uma tarefa de implantação pontual permanece válida por anos. O engenheiro que o criou vai embora. A chave permanece. Ninguém a audita. Acumula permissões ao longo do tempo porque é mais fácil adicionar acesso do que investigar o que é seguro remover. Essas são as "credenciais zumbis" que permanecem em seu ambiente muito tempo depois que a carga de trabalho que as exigia já tiver desaparecido.
A rotação se torna um exercício de crise: quando uma credencial está incorporada em dezenas de pipelines e arquivos de configuração, rotacioná-la significa encontrar primeiro todas as referências a ela. As equipes descobrem referências observando as coisas quebrarem após a rotação. Isso não é uma estratégia de rotação; é uma interrupção controlada.
A questão fundamental é arquitetural: credenciais estáticas são um modelo de identidade projetado para humanos, não para máquinas. Um ser humano pode alternar sua senha e lembrar-se da nova. Uma máquina só precisa saber: “Sou quem digo ser?” — e uma plataforma em nuvem pode responder a essa pergunta criptograficamente, sem nenhum segredo armazenado.
A solução: tokens de curta duração, segurança permanente
O Okta Privileged Access Workload Identity for Automation resolve o problema do “segredo zero” de precisar de uma chave inicial para obter outras credenciais seguras, substituindo credenciais estáticas por provas de identidade assinadas pela plataforma.
A conclusão é simples: uma máquina virtual (VM) do GCP já possui uma identidade criptográfica. Ao associar uma conta de serviço a uma máquina virtual, o GCP pode emitir um JWT assinado com a chave privada do Google que diz, na prática: "Eu sou esta máquina virtual, executando como esta conta de serviço, e este token me foi emitido neste momento específico." Ninguém consegue falsificar esse token sem a chave privada do Google. Ele expira automaticamente e não pode ser reutilizado em outro sistema.
O OPA atua como intermediário de confiança. Você configura uma única vez para dizer: "Confio em JWTs assinados pelo Google para a conta de serviço X". A partir desse momento, qualquer carga de trabalho executada nessa conta de serviço pode comprovar sua identidade para o OPA apresentando seu JWT emitido pelo GCP, e o OPA o trocará por um token de acesso de curta duração. Esse token é então usado para obter um certificado SSH efêmero válido por minutos, não por anos, para conectar-se a um servidor de destino.
Isso não altera o funcionamento do SSH. Trata-se de uma mudança na forma como a identidade é estabelecida antes do início do SSH.
Arquitetura do sistema e mapeamento de componentes
O fluxo de trabalho de autenticação se baseia em um padrão de design de corretor de confiança, no qual o OPA valida declarações de identidade geradas criptograficamente pelo GCP.
| Componente | Função de segurança | Localização |
|---|---|---|
Servidor de metadados do GCP | Endpoint interno do GCP que emite JWTs assinados para qualquer VM sob demanda | Infraestrutura do GCP (não sua VM) |
Conexão de carga de trabalho | Objeto de configuração do OPA que define a relação de confiança com o GCP, especificando quais JWTs aceitar e quais declarações verificar | Painel OPA |
Função de carga de trabalho | Entidade de autorização OPA que mapeia uma identidade de carga de trabalho verificada para um nome de usuário Linux em servidores de destino | Painel OPA |
Política e regra | Define quais funções de carga de trabalho podem acessar quais servidores e por qual método | Painel OPA |
sft (cliente OPA) | Binário de interface de linha de comando (CLI) que lida com a autenticação de cargas de trabalho e a emissão de certificados SSH | VM do executor |
sftd (agente OPA) | Daemon que inscreve o servidor de destino no OPA e configura o SSH para confiar na autoridade certificadora do OPA | VM de destino |
Arquitetura e fluxo de autenticação
Fundamentos de design de segurança
Vinculação de público-alvo OPA: O JWT do GCP é solicitado com a URL do OPA como público-alvo. Mesmo que seja interceptado, não pode ser reproduzido em nenhum outro sistema.
Verificação criptográfica: a OPA obtém as chaves públicas do Google e verifica a assinatura JWT antes de emitir qualquer token. Um JWT falsificado ou adulterado falha.
Prazos de validade TTL (Time-to-Live) rigorosos: o JWT do GCP expira após uma hora. O token OPA permanece válido durante toda a sessão. O certificado SSH é válido pelo período definido. Nada persiste.
Como configurar uma conexão de carga de trabalho do Okta Privileged Access para o GCP
Requisitos e pré-requisitos
Conta do GCP: é necessário ter o faturamento ativado e direitos de proprietário ou editor no projeto.
CLI do gcloud: Instalada e autenticada na estação de trabalho local.
Locatário do OPA: Okta Privileged Access licenciado e acessível através do URL do seu locatário (por exemplo, [https://YOUR-TEAM.pam.okta.com]).
Função de administrador DevOps: Necessária no OPA para criar a conexão de carga de trabalho.
Função de administrador de segurança: Necessária no OPA para ativar a conexão, criar a função de carga de trabalho e criar a política.
Etapa 1: criar a infraestrutura do GCP
Execute esses comandos em sua estação de trabalho local.
1.1 Criar projeto e ativar APIs (GCP)
ID_DO_PROJETO="SEU_ID_DO_PROJETO"
ZONE="VM_LOCATION"
gcloud projects create "$PROJECT_ID" --name="YOUR_PROJECT_ID"
gcloud config set project "$PROJECT_ID"
gcloud services enable compute.googleapis.com iam.googleapis.com
11.2 Criar uma conta de serviço para a VM do executor (GCP)
Esta conta de serviço é a identidade de máquina do executor. Nenhum arquivo de chave é gerado — a vinculação da máquina virtual a esta conta no momento da criação é a prova de identidade.
gcloud iam service-accounts create opa-runner-sa \
--display-name="Conta de serviço OPA Runner" \
--project="$PROJECT_ID"
E-mail da conta de serviço gerada: <YOUR_PROJECT_ID>opa-runner-sa@.iam.gserviceaccount.com
1.3 Criar instâncias de computação de execução e de destino (GCP)
# VM do runner
gcloud compute instances create runner-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--service-account=opa-runner-sa@${PROJECT_ID}.iam.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--tags=opa-runner
# VM de destino
gcloud compute instances create target-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=opa-target
Nota: Os servidores acima estão configurados usando “machine-type” : “e2-medium ” e “image-family” : “ubuntu-2204-lts”. Você pode escolher seu próprio tipo de máquina e família de imagens.
1.4 Configurar regras de firewall (GCP)
# Permitir acesso SSH interno do executor ao destino
gcloud compute firewall-rules create allow-runner-to-target \
--allow=tcp:22 \
--source-tags=opa-runner \
--target-tags=opa-target \
--project="$PROJECT_ID"
# Permitir HTTPS de saída do destino para comunicação do agente OPA
gcloud compute firewall-rules create allow-egress-opa \
--direction=EGRESS \
--allow=tcp:443 \
--target-tags=opa-target \
--project="$PROJECT_ID"
Etapa 2: configurar a VM de execução (GCP)
A máquina virtual do runner requer apenas o binário sft. Não está cadastrado para nenhum usuário no OPA.
# Conecte-se à VM do Runner via SSH
gcloud compute ssh runner-vm --zone="$ZONE"
# Instale as dependências e o binário do cliente sft
# Instale a chave do repositório e adicione o repositório PAM do Okta
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Atualize o repositório e instale as ferramentas do cliente SFT
sudo apt-get update && sudo apt-get install -y scaleft-client-tools
# Confirme o comprovante de identidade anexado
curl -sf -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email"
# Saída esperada: opa-runner-sa@opa-workload-demo.iam.gserviceaccount.com
saída
Etapa 3: configurar a VM de destino
3.1 Configurar o painel de controle do OPA e gerar o token de inscrição do servidor (Okta)
- Acesse o Painel de Controle do OPA → Administração de Recursos → Gerenciamento de Recursos → Criar Grupo de Recursos → Criar Projeto ou Grupo de Recursos Existente → Salvar
- Nome: GCP_Servers_Proj
- Descrição: servidores de destino do GCP para demonstração de carga de trabalho
- Navegue até GCP_Servers_Proj → Projeto → Tipo de recurso - Servidores → Configurações → Token de inscrição → Exibir → Criar token de inscrição
- Select OS: Linux
- Copie o token de inscriçãogerado
3.2 Instalar e iniciar o agente sftd na VM de destino (baseada no GCP)
# Conecte-se à VM de destino via SSH
gcloud compute ssh target-vm --zone="$ZONE"
# Instalar dependências e o daemon sftd
# Instale a chave do repositório e adicione o repositório PAM do Okta
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Atualize o repositório e instale as ferramentas do servidor SFT
sudo apt-get update && sudo apt-get install -y scaleft-server-tools
# Salvar token de configuração de inscrição
sudo mkdir -p /var/lib/sftd
echo "SEU_TOKEN_DE_INSCRIÇÃO_AQUI" | sudo tee /var/lib/sftd/enrollment.token > /dev/null
# Restringir permissões de arquivo por motivos de segurança
sudo chmod 600 /var/lib/sftd/enrollment.token
# Ativar e verificar o estado do daemon
sudo systemctl enable sftd && sudo systemctl start sftd
sleep 5
sudo systemctl status sftd --no-pager
saída
3.3 Verificar inscrição
Verifique o painel do OPA para confirmar se o status mostra "Inscrito": Painel do OPA → GCP_Servers_Proj → Servidores → target-vm (Status: Inscrito) ✓
Etapa 4: Configurar a conexão e as funções da carga de trabalho do OPA (Okta)
4.1 Criar e ativar a conexão de carga de trabalho (administrador DevOps e administrador de segurança)
No painel do OPA, navegue até Administração do DevOps → Conexões de carga de trabalho → Criar conexão de carga de trabalho.
Escolha o provedor Google Cloud.
Insira os detalhes do ID do cliente do app:
ID do cliente do aplicativo: Insira o ID do cliente do seu aplicativo (a conta de serviço criada na etapa anterior dentro do projeto do GCP)
Marque Escopo para e-mail (o e-mail é gerado automaticamente)
Definir parâmetros:
Nome da conexão: OKTA-OPA-Demo
Tempo de vida do token: 3600 segundos
Declarações obrigatórias: aud = [https://YOUR-TEAM.pam.okta.com] e iss = [https://accounts.google.com]
Clique em Criar conexão de carga de trabalho.
- Alternar para administrador DevOps: abra OKTA-OPA-Demo → Ações → Ativar.
4.2 Criar função de carga de trabalho (Administrador de segurança)
Acesse Administração de segurança → Funções de carga de trabalho → Criar função de carga de trabalho.
Configurar atributos:
Nome: OKTA-OPA-WR
Conexão de carga de trabalho: OKTA-OPA-Demo
Clique em Salvar função de carga de trabalho. O OPA atribui automaticamente um nome de usuário Linux (wl_okta_opa_wr).
4.3 Configurar políticas e regras (administrador de segurança)
Acesse Administração de Segurança → Políticas → Criar Política → Padrão
Nome: Acesso ao servidor NHI
Selecione os grupos de recursos: Todos os grupos de recursos
Em Adicionar entidades principais, adicione a função de carga de trabalho OKTA-OPA-WR.
Em Adicionar regra à política, Select Regra do servidor:
Nome daregra: Permitir SSH para a função de carga de trabalho
Tipo desessão: Sessão SSH do servidor
Contas: Ativar Select contas por nome → Destino: vm-alvo / raiz
Crucial: NÃO habilite MFA ou Access Requests (tarefas sem interface gráfica não podem responder a prompts interativos).
Clique em Salvar política e, em seguida, acesse Ações → Publicar.
Etapa 5: verificar e testar a execução (baseada no GCP)
5.1 Preparar o script de automação de verificação
Conecte-se novamente à máquina virtual runner-vm via SSH e prepare o script de automação:
gcloud compute ssh runner-vm --zone="$ZONE"
#!/bin/bash
#
# Script de demonstração de identidade de carga de trabalho do OPA
# Baseado em: Okta Privileged Access - Introdução às identidades de carga de trabalho
#
# ─── DEFINIR VARIÁVEIS DE AMBIENTE ────────────────────────────────────────────────
# Público-alvo = seu endereço OPA (deve corresponder à declaração aud esperada pela OPA)
AUDIENCE="https://opa-gcp.pam.okta.com"
# URL de metadados do GCP para obter o JWT
METADATA_URL="http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUDIENCE}&format=full"
# Equipe e endereço da OPA (o sft lê essas informações do ambiente)
export SFT_TEAM="opa-gcp"
export OPA_ADDR="https://demo-opa-gcp-demo.pam.okta.com"
# Os nomes devem corresponder exatamente aos que você criou no painel do OPA
CONNECTION_NAME="okta-opa-demo"
ROLE_NAME="okta_opa_wr"
# Nome do servidor de destino (conforme cadastrado no OPA — o nome do host)
TARGET_SERVER="target-vm"
# ─── PASSO 1: OBTER JWT DE IDENTIDADE DO GCP ──────────────────────────────────────────────
echo "------------------------------------------------------------"
echo "PASSO 1: Obtendo o JWT do servidor de metadados do GCP"
echo "------------------------------------------------------------"
ID_TOKEN=$(curl -s -H "Metadata-Flavor: Google" "$METADATA_URL" | tr -d '\n\r')
if [[ "$ID_TOKEN" == eyJ* ]]; then
GCP_JWT="$ID_TOKEN"
# Decodificar e exibir a janela de validade
PAYLOAD=$(echo "$GCP_JWT" | cut -d. -f2 | base64 --decode 2>/dev/null)
EXP=$(echo "$PAYLOAD" | jq -r '.exp')
ISS=$(echo "$PAYLOAD" | jq -r '.iss')
EMAIL=$(echo "$PAYLOAD" | jq -r '.e-mail')
NOW=$(date +%s)
DIFF=$((EXP - NOW))
echo "Emissor : $ISS"
echo "E-mail : $EMAIL"
echo "Público : $AUDIENCE"
echo ""
echo "VALOR DE GCP_JWT:"
eco "${GCP_JWT:0:80}... (truncado)"
echo ""
echo "Sucesso: JWT obtido."
echo "O token é válido por mais $DIFF segundos (aproximadamente $((DIFF / 60)) minutos)."
outro
echo "ERRO: Falha ao obter o JWT do servidor de metadados."
echo "Certifique-se de que este script esteja sendo executado em uma VM do GCP com uma conta de serviço anexada."
exit 1
fi
# Exportar para uso da sft
export GCP_TOKEN="$GCP_JWT"
echo ""
# ─── PASSO 2: TROCAR JWT DO GCP POR TOKEN OPA ───────────────────────────────────
echo "------------------------------------------------------------"
echo "ETAPA 2: Autenticando a carga de trabalho com o OPA para obter o OPA_TOKEN"
echo "------------------------------------------------------------"
echo "Executando:"
echo "sft wl authenticate --team $SFT_TEAM \\"
echo "--conexão $CONNECTION_NAME"
echo " --role-hint $ROLE_NAME \\"
echo " --jwt-env GCP_TOKEN"
echo ""
OPA_TOKEN=$(sft wl authenticate \
--team "$SFT_TEAM" \
--conexão "$CONNECTION_NAME" \
--role-hint "$ROLE_NAME" \
--jwt-env GCP_TOKEN 2>&1 | tr -d '\n\r')
export OPA_TOKEN
if [[ "$OPA_TOKEN" == *"error"* ]] || [[ -z "$OPA_TOKEN" ]]; then
echo "ERRO: Falha ao obter OPA_TOKEN."
echo "Detalhe: $OPA_TOKEN"
echo ""
echo "Lista de verificação:"
echo " 1. O status da conexão de carga de trabalho é ATIVO (não Rascunho)?"
echo " 2. O nome da conexão '$CONNECTION_NAME' corresponde exatamente?"
echo " 3. A reivindicação aud é igual a '$AUDIENCE'?"
echo " 4. A declaração de e-mail corresponde à SA na Conexão de Carga de Trabalho?"
exit 1
outro
eco "SUCESSO: OPA_TOKEN obtido."
echo ""
echo "VALOR DO OPA_TOKEN:"
echo "${OPA_TOKEN:0:80}... (truncado)"
fi
echo ""
# ─── PASSO 3: USAR O TOKEN OPA PARA ACESSAR O SERVIDOR DE DESTINO ───────────────────────
echo "------------------------------------------------------------"
echo "PASSO 3: Testando OPA_TOKEN com comandos sft"
echo "------------------------------------------------------------"
echo ""
echo "3a. Lista dos servidores que esta carga de trabalho pode acessar:"
sft list-servers
echo ""
echo "3b. Conectando ao $TARGET_SERVER como root e executando um comando:"
sft ssh --comando "hostname" e "whoami" e "date" echo 'Acesso à carga de trabalho SUCESSO'
"$TARGET_SERVER"
echo ""
echo "------------------------------------------------------------"
echo "CONCLUÍDO: demonstração de identidade da carga de trabalho concluída."
echo "Verifique o Registro do Sistema Okta em busca de dois eventos:"
echo " 1. Troca de token (autenticação)"
echo " 2. Login SSH no servidor"
echo "------------------------------------------------------------"
5.2 Execute o script de automação
Execute o script de automação:
$ bash ~/opa-workload-test.sh
5.3 Saída esperada e registros de auditoria
Após a execução, o terminal retorna:
O resultado demonstra um fluxo completo de autenticação SSH sem credenciais em três etapas:
Recuperação de identidade do GCP: A VM do executor solicita um JWT assinado pela plataforma diretamente dos metadados do Google Cloud (accounts.google.com) para a conta de serviço opa-runner-sa, estabelecendo sua identidade sem segredos armazenados.
Troca de token: O script passa o JWT do GCP para o Okta Privileged Access através do sft wl authenticate. O OPA verifica a assinatura criptográfica do Google e emite um OPA_TOKEN mapeado para a função okta_opa_wr.
Execução sem senha: o OPA descobre a máquina virtual de destino e usa um certificado SSH efêmero baseado em tempo para executar comandos no servidor remoto.
A resposta do servidor de destino exibe seu nome de host (target-vm), o usuário de carga de trabalho atribuído pelo sistema (wl_okta_opa_wr) e o carimbo de data/hora de execução. Isso confirma o acesso SSH completo e auditável, baseado inteiramente em provas de plataforma em tempo de execução, em vez de chaves estáticas.
Auditabilidade e registros do sistema
Cada ciclo de autenticação gera eventos estruturados no Registro do Sistema Okta (console de administração do Okta → Relatórios → Registro do Sistema).
Você pode aplicar o seguinte filtro para visualizar os registros do sistema necessários:
eventType eq "pam.user_creds.issue" and actor.type eq "WorkloadPrincipal"
Elimine segredos estáticos da sua infraestrutura de automação
Ao substituir chaves SSH permanentes e arquivos de contas de serviço por provas de identidade criptográficas assinadas pela plataforma, suas equipes de segurança e engenharia podem alcançar um verdadeiro acesso ao servidor com Zero Trust sem interromper os pipelines de automação. O Okta Privileged Access simplifica o gerenciamento de identidades e acessos não humanos, unindo federação dinâmica de cargas de trabalho, emissão de certificados efêmeros e auditabilidade abrangente em um único plano de controle.
Descubra como o Okta Privileged Access protege as identidades de máquinas e humanos em todos os seus recursos na nuvem.
