# HSM HML - validação da API em `:6443`

Data: 2026-06-22
Ambiente: Monetarie HML AWS `sa-east-1`
Escopo: retomar teste funcional do vHSM `60042` após migração da aplicação para a VPC `10.45.0.0/16`

## Resultado

O ambiente de rede está OK para o HSM HML:

- DNS `cloudhsm-hml.priv.rtmcloud.net.br` resolve para `10.173.1.247`.
- TCP `cloudhsm-hml.priv.rtmcloud.net.br:6443` abre a partir do OpenVPN HML.
- O túnel SSM local via OpenVPN também alcança `cloudhsm-hml.priv.rtmcloud.net.br:6443`.

O endpoint `:6443`, porém, responde como Kubernetes API Server, não como API KMIP direta:

- `GET /version`: HTTP `200`, Kubernetes `v1.31.12`.
- `GET /readyz`: HTTP `200`, `ok`.
- `GET /livez`: HTTP `200`, `ok`.
- `GET /openapi/v2`: HTTP `403`, usuário `system:anonymous`.
- `POST /v1/kmip/60042/get-session-credential`: HTTP `403`, usuário `system:anonymous`.
- Com `Authorization: Bearer <token HSM>`: HTTP `401 Unauthorized`.
- Com Basic Auth usando usuário/token do HSM: segue HTTP `403` como `system:anonymous`.

## Credenciais

Os secrets do AWS Secrets Manager para PIX e SPB batem com o arquivo local de credenciais de HML:

- `monetarie/homolog/hsm/pix/hml/crypto_user`
- `monetarie/homolog/hsm/pix/hml/token`
- `monetarie/homolog/hsm/spb/hml/crypto_user`
- `monetarie/homolog/hsm/spb/hml/token`

Nenhum token, senha, sessão ou payload sensível foi registrado neste documento.

## Conclusão técnica

O caminho de rede até o endpoint informado está funcional, mas a porta `6443` está protegida por autenticação de camada Kubernetes/gateway antes do serviço KMIP.

Com as credenciais HSM atuais (`cryptoUser` e token de aplicação), o request não chega ao contrato KMIP esperado:

`POST /v1/kmip/60042/get-session-credential`

Por isso, a sessão HSM ainda não foi obtida e os testes `sign-rsa`, `signature-verify-rsa`, `cipher/rsa/encrypt` e `cipher/rsa/decrypt` não devem ser marcados como executados no vHSM real `60042`.

## Próximo dado necessário da RTM

Solicitar à RTM os itens abaixo:

- Credencial HTTP/Kubernetes/gateway necessária para atravessar a porta `6443` até o serviço KMIP.
- Confirmação do path correto caso o KMIP esteja exposto por proxy Kubernetes, por exemplo via service proxy ou ingress específico.

Enquanto isso, manter `RTM_HSM_ENABLED=false` nas cabines PIX e SPB.

## Revalidação pela máquina do Luiz - 2026-06-22 17:53 BRT

Com a VPN correta conectada e usando a liberação atual:

- Rota para `10.173.1.247`: gateway `10.250.0.1`, interface `utun9`.
- DNS via resolvers internos:
  - `10.250.0.1` -> `10.173.1.247`
  - `10.45.0.2` -> `10.173.1.247`
  - `10.45.1.30` -> `10.173.1.247`
- TCP `10.173.1.247:6443`: conectado.
- Porta `60042`: não é porta TCP da API; é o ID do vHSM usado no path `/v1/kmip/60042/...`.
- `GET https://cloudhsm-hml.priv.rtmcloud.net.br:6443/version` com `--resolve`: HTTP `200`.
- `GET /readyz` e `/livez` com `--resolve`: HTTP `200`.
- `GET /`: HTTP `403`.

Os testes de `POST /v1/kmip/60042/get-session-credential` continuaram sem retorno de sessão:

- Body com credencial de aplicação, sem auth HTTP: HTTP `403`, usuário `system:anonymous`.
- Body com credencial de aplicação + Basic Auth de aplicação: HTTP `403`, usuário `system:anonymous`.
- Body com credencial de aplicação + Bearer token de aplicação: HTTP `401 Unauthorized`.
- Body com credencial de aplicação + Basic/Bearer VCO: HTTP `403` ou `401`, sem `returnValue`.
- Body com credencial VCO + Basic/Bearer VCO: HTTP `403` ou `401`, sem `returnValue`.

Observações operacionais:

- O macOS possui resolver supplemental correto para `priv.rtmcloud.net.br` em `10.250.0.1`, mas também há outro resolver para o mesmo domínio apontando para `10.0.33.2` e `10.0.17.2`; esses dois não responderam no teste. Isso pode travar resolução local por hostname em algumas aplicações. O teste funcional foi executado com `--resolve` para isolar DNS de rede/API.
- A porta `6443` usa TLS com cadeia self-signed para o trust store local; sem `-k`, o `curl` falha com erro de validação de certificado.
- ECS HML live: `pix-api` e `spb-api` seguem com `RTM_HSM_ENABLED=false`.
- Correção aplicada em Terraform: `RTM_HSM_BASE_URL=https://cloudhsm-hml.priv.rtmcloud.net.br:6443`; `RTM_HSM_VHSM=60042`.

## Correção operacional - 2026-06-22

- `pix-api` atualizado para task definition `monetarie-pix-api-homolog:16`.
- `spb-api` atualizado para task definition `monetarie-spb-api-homolog:12`.
- Ambos estão com `RTM_HSM_BASE_URL=https://cloudhsm-hml.priv.rtmcloud.net.br:6443`, `RTM_HSM_VHSM=60042` e `RTM_HSM_ENABLED=false`.
- Rota TGW criada para o endpoint de teste RTM/RSFN: `200.160.160.0/22 -> tgw-attach-0b451500fe3362561` (Direct Connect Gateway).
- O IP `200.160.162.200` pertence a esse bloco e a rota local pela VPN entra em `utun9 -> 10.250.0.1`.
- Mesmo com rota TGW ativa e NAT do OpenVPN presente para `200.160.160.0/22`, `http://200.160.162.200:63351/index.html` ainda retorna timeout a partir do Mac e da EC2 OpenVPN. O bloqueio restante não é ausência de rota na VPC/TGW; precisa de confirmação do lado RTM/DX para esse destino/porta.