“Lockless keys” por plenty.r. está licenciado por CC BY-SA 2.0.
Neste artigo, explicamos como modificar um baker de Tezos para utilizar um sistema de gerenciamento de chaves (KMS) do Google Cloud e o software Signatory do ECAD Labs para assinar operações de consenso.
Talvez você queira fazer isso por vários motivos:
- aumentar a segurança ou a resiliência de sua configuração.
- reduzir os tempos de assinatura para melhorar o desempenho.
O guia pressupõe a preexistência de um baker, no local ou na nuvem. Você não implantará nenhuma máquina virtual na nuvem. Todos os processos (nó, baker e Signatory) são considerados em execução nessa configuração preexistente. Os custos da nuvem incorridos por essa configuração são mínimos.
No entanto, há riscos. Consulte a seção Risco abaixo para obter detalhes.
Há dois requisitos principais para converter uma configuração de baking existente para usar uma solução KMS. Primeiro, você deve obter uma chave do KMS e, segundo, deve instalar algum software para que seu baker possa usar essa chave. Neste guia, estamos usando o Google KMS Service. O Signatory é o software usado para permitir a comunicação entre seu nó e o KMS.
Observe que a AWS (Amazon Web Services) possui um KMS semelhante. Nosso artigo anterior explica como configurar um baker de nuvem utilizando o KWS da AWS:
Implante um Baker de Tezos na Nuvem usando a Carteira Ledger, o Assinante Remoto e a Chave de Consenso por Oxhead Alpha.
Habilite o Gerenciamento de Chaves da Nuvem em sua conta do Google Cloud
Você precisa de uma conta do Google Cloud. Certifique-se de que suas credenciais de acesso sejam seguras e use a autenticação de dois fatores sempre que disponível. Qualquer pessoa com acesso à sua conta do Google Cloud pode adulterar seu baker. Se essa for uma conta corporativa, certifique-se de que o gerenciamento de identidade e acesso (IAM) esteja configurado de acordo com a política de segurança de sua organização.
Procure por "KMS" na barra de pesquisa.
Trabalharemos em um projeto dedicado a essa configuração. No canto superior direito, clique em "Create project" (Criar projeto) e dê um nome a ele.
Em seguida, você será convidado a ativar a API do KMS. Habilite-a.
Em seguida, volte para "KMS" na barra de pesquisa e Crie seu primeiro chaveiro (key ring):
Utilize os seguintes parâmetros:
Conta de serviço
Configure o acesso ao aplicativo criando uma conta de serviço e atribuindo a ela uma função personalizada com apenas as permissões necessárias para fazer o bake.
Vamos começar criando a função. Na barra de pesquisa, busque "Role" (Função) e crie uma nova função com as seguintes permissões:
Veja Documentação do Signatory para obter a lista completa de permissões necessárias
Em seguida, selecione "Service Account" (Conta de serviço) na barra de pesquisa e crie uma nova conta de serviço. Atribua a ela a função que você criou.
Depois disso, selecione a conta de serviço e crie uma chave no menu "Keys" (Chaves). Selecione o formato JSON.
Essa não é a chave privada do baker. Essa é a chave usada pelo Signatory para se conectar ao KMS. No entanto, ela é confidencial. Qualquer pessoa com acesso a ela pode adulterar seu baker. Não a compartilhe!
Configuração do Signatory
Faça o download do Signatory na sua máquina baking.
Crie um arquivo signatory.yaml assim:
server:
address: :6732
utility_address: :9583
vaults:
gcp:
driver: cloudkms
config:
project: tezos-baker-kms
location: us-west1
key_ring: tezos-baker-kms
application_credentials: ./tezos-baker-kms-dcf4ee576083.json
Em seguida, execute o seguinte:
export GOOGLE_APPLICATION_CREDENTIALS="tezos-baker-kms-dcf4ee576083.json"
./signatory-cli list -c signatory.yaml --base-dir .
Você verá o hash da chave pública (começando com tz3 ). Anote-o.
Para obter mais detalhes, leia as seguintes páginas da documentação do Signatory:
- Google KMS: https://signatory.io/docs/gcp_kms
- Tezos Bakers: https://signatory.io/docs/bakers
Registrar a Chave de Consenso
Embora seja possível fazer o bake diretamente usando uma conta do KMS, recomendamos usá-lo como chave de consenso. Na verdade, é importante que a chave do baker esteja sob seu controle caso você acabe perdendo o acesso ao KMS. Isso pode ocorrer devido à perda de credenciais ou ao encerramento da conta.
Primeiro, configuramos o Signatory para permitir a assinatura de operações de consenso pela chave de consenso. Adicione na parte inferior do signatory.yaml :
tezos:
tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5:
log_payloads: true
allow:
block:
endorsement:
preendorsement:
Substitua o endereço tz3 acima pelo tz3 obtido na etapa anterior. Esse é o hash da chave pública de sua chave de consenso.
Em seguida, inicie o signatory:
./signatory --base-dir . -c signatory.yaml
e adicione o endereço ao seu baker:
./octez-client import secret key kms-consensus-key http://localhost:6732/tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5
Agora você pode registrar a chave de consenso:
./octez-client register key mybaker as delegate with consensus key kms-consensus-key
Ou, se o seu baker já estiver ativo, você poderá configurar a chave de consenso:
./octez-client set consensus key for mybaker to kms-consensus-key
Isso levará algum tempo (6 ciclos na rede principal) para se tornar ativo.
Quando estiver ativo, você deverá passar o apelido da chave de consenso como um argumento do seu comando baker:
./octez-baker-<Protocol> run with local node ~/.tezos-node/ \
kms-consensus-key --liquidity-baking-toggle-vote pass
Nota: Substitua <Protocol> pelo apelido do protocolo ativo no momento.
Quando você começar a validar, o baker mostrará:
May 19 08:16:52.265 - alpha.baker.transitions: received new proposal BLUervU3VUKv4QsH52aG1EAoqManwFbtLU8AeBGbFD54raJTmzN at
May 19 08:16:52.265 - alpha.baker.transitions: level 1766, round 0
May 19 08:16:52.354 - alpha.baker.actions: injected preendorsement opaWSBDTpk4PaNrkELpyntbaGc7uBTRcd4rtQc6teYQB3KJp4Xj
May 19 08:16:52.354 - alpha.baker.actions: for kms-consensus-key (tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5)
May 19 08:16:52.354 - alpha.baker.actions: on behalf of tz1XfNWYxfKRskaEZxytFJ3WXagcb7XJ6g76 for level 1766, round 0
May 19 08:16:52.538 - alpha.baker.actions: injected endorsement onwkg2suixtRCfkfNhhJsuW5WSd1h4TpjXzpgQBh8yKhTftg98z for
May 19 08:16:52.538 - alpha.baker.actions: kms-consensus-key (tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5)
May 19 08:16:52.538 - alpha.baker.actions: on behalf of tz1XfNWYxfKRskaEZxytFJ3WXagcb7XJ6g76 for level 1766, round 0
e o Signatory mostrará:
INFO[63770] Requesting signing operation chain_id=NetXxkAx4woPLyu lvl=1767 pkh=tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5 request=endorsement vault=CloudKMS vault_name=projects/tezos-baker-kms/locations/us-west1/keyRings/tezos-baker-kms
INFO[63770] About to sign raw bytes chain_id=NetXxkAx4woPLyu lvl=1767 pkh=tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5 raw=13ed9d217c7e7b09706fd5fd012107a88fad7e29720f294ee3f3d78cde6056a0f00810353f150010000006e700000000b046a665219aee432feb4d76b41259bab5c95695e761ab90e31b94ee1b8a70eb request=endorsement vault=CloudKMS vault_name=projects/tezos-baker-kms/locations/us-west1/keyRings/tezos-baker-kms
INFO[63770] Signed endorsement successfully chain_id=NetXxkAx4woPLyu lvl=1767 pkh=tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5 request=endorsement vault=CloudKMS vault_name=projects/tezos-baker-kms/locations/us-west1/keyRings/tezos-baker-kms
INFO[63770] POST /keys/tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5 duration=71.569304ms hostname="localhost:6732" method=POST path=/keys/tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5 start_time="2023-05-19T08:17:22-07:00" status=200
Configure o Signatory como Serviço
Para garantir que o Signatory seja executado em segundo plano, crie um serviço Systemd.
Isso pressupõe que o seu baker esteja sendo executado no Linux.
Como root (raiz), escreva o seguinte arquivo:
# cat /etc/systemd/system/signatory.service
[Unit]
Description=signatory tezos signer.
[Service]
ExecStart=/path/to/signatory --base-dir /path/to -c /path/to/signatory.yaml
[Install]
WantedBy=multi-user.target
Em seguida:
systemctl daemon-reload
systemctl enable signatory.service
systemctl start signatory.service
O Signatory será reiniciado automaticamente após a reinicialização do computador, assim como deve acontecer com seu baker.
Riscos
Os riscos de fazer o baking com uma chave de consenso na nuvem são:
- exposição da chave: Embora a chave resida em um KMS dentro das instalações do provedor da nuvem, em última análise, ela não está sob seu controle. Você está confiando no provedor de KMS (neste caso, o Google) para protegê-la. Veja Documento de Arquitetura do KMS do Google para obter mais detalhes.
- assinatura não autorizada: embora a chave em si nunca seja exposta, qualquer pessoa de posse da chave da conta de serviço pode assinar qualquer mensagem. O Signatory proíbe qualquer assinatura que não seja de mensagens de consenso, mas essa proteção não é eficaz contra qualquer pessoa que interaja diretamente com o KMS.
- equívoco ou dupla assinatura/endosso: qualquer pessoa que possua a chave da conta de serviço pode criar uma mensagem de dupla assinatura que pode ser denunciada por qualquer baker. O baker que faz a denúncia recebe metade do depósito de segurança.
- disponibilidade: o provedor da nuvem pode encerrar sua conta se você não pagar sua fatura ou violar os termos e condições.
- perda de credenciais: talvez você não consiga fazer login na sua conta na nuvem. Nesse caso, é possível girar a chave de consenso usando a chave de baking principal. Mas é necessário aguardar 6 ciclos para que a alteração seja efetivada.
Custo
O baking com uma chave de consenso no GCP é muito barato:
- uma chave KMS custa US$2.50 por mês
- então custa US$ 0,15 por 10.000 assinaturas
Em geral, os custos de nuvem incorridos por um baker são inferiores a US$ 10/mês.
Exclusão
Para excluir sua chave KMS e interromper todos os custos da nuvem, basta excluir seu projeto do Google Cloud.
Esse artigo foi escrito por Nicolas Ochem e traduzido por Fátima Lima. O original pode ser lido aqui.
Latest comments (0)