Este artículo es una traducción de Nicolas Ochem, hecha por Héctor Botero. Puedes encontrar el artículo original aquí.
Sería genial escucharte en nuestro Discord, puedes contarnos tus ideas, comentarios, sugerencias y dejarnos saber lo que necesitas.
Si prefieres puedes escribirnos a @web3dev_es en Twitter.
En este artículo, explicaremos cómo modificar un Tezos Baker para utilizar el Google Cloud Key Management System (KMS) y el software Signatory por ECAD Labs para poder firmar las operaciones de consenso.
Deberías hacer esto por algunas razones:
- Incrementar la seguridad y resiliencia de tu configuración
- Reducir los tiempos de firmas para mejorar el rendimiento
Esta guía asume un baker preexistente, en prem o en la nube. No desplegarás ninguna máquina virtual en la nube. Todos los procesos (nodo, baker y firmante) se asumen que se ejecutan en esta configuración preexistente. Los costos correspondientes a la nube, hechos por esta configuración, son mínimos.
Aún así hay riesgos. Por favor, revisa la sección de riesgos para detalles.
Hay dos requisitos principales para convertir una configuración baking existente para usar una solución KMS. Primero, debes obtener una clave desde el KMS y en segundo lugar, debes instalar algún software para que tu baker pueda usar esta clave. En esta guía, estaremos usando el Google KMS Service. Signatory es el software usado para permitir la comunicación entre tu nodo y el KMS.
Date cuenta que el AWS tiene un ofrecimiento KM similar. Nuestro artículo anterior explica cómo configurar un baker en la nube aprovechando AWS KMS:
Despliega un Tezos Baker en la Nube usando un Registro de Cartera, una Firma Remota y una Clave Consenso, por Oxhead Alpha.
Permitir un Administrador de Claves en la Nube con tu cuenta de Google Cloud
Necesitas una cuenta de Google Cloud. Asegúrate que tus credenciales de acceso sean seguras y usa autenticación de dos factores cuando esté disponible. Cualquiera con acceso a tu cuenta de Google Cloud puede alterar tu baker. Si es una cuenta empresarial, asegúrate que la Identidad y la Administración de Acceso (IAM) esté configurado de acuerdo a la política de seguridad de tu organización.
Busca “KMS” en la barra de búsquedas.
Trabajaremos en un proyecto dedicado a esta configuración. En el tope derecho haz click en “Create project” y nómbralo.
Luego te invita a que habilites la API KMS. Habilítala.
Luego, vuelve a “KMS” desde la barra de búsquedas y crea tu primer llavero.
Usa los siguientes parámetros:
Cuenta de Servicio
Configura el acceso de la aplicación creando una cuenta de servicio, dándole un rol personalizado únicamente con los permisos necesarios para hacer el bake.
Empecemos creando el rol. Primero, desde la barra de búsqueda, busca “Role” y luego crea un nuevo rol con los siguientes permisos:
Luego selecciona “Service Account” desde la barra de búsqueda y luego crea una nueva cuenta de servicio. Asigna el rol que has creado.
Una vez hecho, selecciona la cuenta de servicio y crea una clave bajo el menú “Keys”. Selecciona el formato JSON.
Esta no es la clave privada del baker. Esta es la clave usada por Signatory para conectarla con el KMS. Aún así, es sensible. Cualquiera con el acceso puede hacer alteraciones con tu baker. ¡No lo compartas!
Configuración de Signatory
Descarga Signatory en tu máquina para baking.
Crea un archivo signatory.yaml como:
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
Luego, ejecuta lo siguiente:
export GOOGLE_APPLICATION_CREDENTIALS="tezos-baker-kms-dcf4ee576083.json"
./signatory-cli list -c signatory.yaml --base-dir .
Luego verás el hash de la clave pública (comenzado con tz3). Toma nota de ellos.
Para más detalles, lee las páginas con los documentos de Signatory:
- Google KMS: https://signatory.io/docs/gcp_kms
- Tezos Baker: https://signatory.io/docs/bakers
Registro de la Clave de Consenso
Mientras que es posible hacer el baking directamente usando una cuenta KMS, recomendamos usarla como la clave de consenso. Ciertamente, es importante que la clave baker esté en tu control si pierdes acceso al KMS. Esto puede ser por la pérdida de los credenciales o la cancelación de la cuenta.
Primero, configuramos signatory para permitir las operaciones de la firma de consenso por la clave consenso. Añade al final signatory.yaml:
tezos:
tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5:
log_payloads: true
allow:
block:
endorsement:
preendorsement:
Reemplaza la dirección tz3 de arriba con el tz3 obtenido en el paso anterior. Este es el hash de la clave pública de tu clave consenso.
Luego, ejecuta signatory:
./signatory --base-dir . -c signatory.yaml
Y luego añade esta firma a tu baker:
./octez-client import secret key kms-consensus-key http://localhost:6732/tz3iGkaoKJ5uZ51gotVp6x7wMkGPX1U5jNo5
Ahora puedes registrar una clave consenso:
./octez-client register key mybaker as delegate with consensus key kms-consensus-key
O, si tu baker ya está activo, puedes seleccionar la clave consenso:
./octez-client set consensus key for mybaker to kms-consensus-key
Esto tomará algún tiempo (6 ciclos de mainnet) para que esté activo.
Cuando esté activo, debes pasar el alias de la clave consenso como un argumento en tu comando baker:
./octez-baker-<Protocol> run with local node ~/.tezos-node/ \
kms-consensus-key --liquidity-baking-toggle-vote pass
Nota: reemplaza con el alias en el protocolo actualmente activo.
Una vez que comiences la validación, el baker te 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
Signatory te 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
Establece el Servicio Signatory
Para asegurarte que signature se ejecute en segundo plano, crea un servicio Systemd.
Esto asume que tu baker está siendo ejecutando en Linux.
En la raíz, escribe el siguiente archivo:
# 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
Luego:
systemctl daemon-reload
systemctl enable signatory.service
systemctl start signatory.service
Signatory luego reiniciará automáticamente luego de reiniciar, como el baker debería hacer.
Riesgos
Los riesgos de hacer baker con la clave consenso en la nube son:
- exposición de la clave: mientras que la clave resida en las premisas del proveedor de KMS en la nube, no está últimamente bajo tu control. Estás confiando en el proveedor KMS (En este caso, Google) para asegurarlo. Revisa los documentos de la arquitectura KMS de Google
- firma sin autorización: mientras que la clave en sí nunca sea expuesta, cualquiera que tenga posesión de la clave de la cuenta del servicio puede firmar cualquier mensaje. Signatory prohíbe cualquier firma, pero no los mensajes de consenso, aún así esta protección no es efectiva contra cualquiera que esté interactuando con el KMS directamente.
- equivocación o doble baking/respaldo: cualquiera que posea la clave de la cuenta de servicio puede crear un mensaje de doble firma, el cual luego puede ser denunciado por cualquier baker. El baker que hace la denuncia obtiene la mitad del seguro de depósito.
- disponibilidad: el proveedor de la nube puede terminar tu cuenta, si no pagas tus facturas o si están violando los términos y condiciones
- pérdida de credenciales: puede ser que no puedas entrar en tu cuenta de la nube. En este caso, es posible rotar la clave consenso usando la clave principal del baker. Pero, es necesario esperar 6 ciclos para que el cambio tenga efecto
Costo
Baking con la clave consenso en GCP es muy barato:
- una clave KMS cuesta 2.50$ por mes
- luego cuesta 0.15$ por cada 10.000 firmas
En general, los costos incurridos en la nube para un baker serán debajo de los 10$ por mes
Derribar el proyecto
Para borrar tu clave KMS y detener cualquier costo de la nube, simplemente elimina el proyecto en tu Google Cloud.
Discussion (0)