How PYUR Pool is Secured

We've worked hard to ensure pyur pool uses state of the art technologies and practices to provide ease of mind when delegating with us. Below are some highlights that proudly separate us from other pools. of

UPTIME

Dockerized cardano nodes ensure reproducible, immutable and isolated pool deployments using container technologies.
Kubernetes allows us to manage, scale and upgrade our pool gracefully. Upgrades are applied one node at a time and rolled back automatically if unsuccessful without impacting the pool's availability. This allows us to add additional relays with a single command. Unhealthy or failing nodes are replaced and restarted automatically based on the status of their Liveness and Readiness checks allowing the pool to self-heal.
Relays in different geographical areas ensure that we have redundancy built into the system in case of outages, allowing our block producer node to continue to process ADA transactions and mint blocks no matter the scenario
Cloud-deployed VMs and Load Balancers provide additional reliability to our pool in case of natural disasters, power outages, and network interruptions

SECURITY

Cold keys are managed in an air-gapped (offline) machine, with keys themselves stored encrypted on FIPS 140-2 validated hardware. Multiple offline backups of the keys are stored in multiple geographical locations to ensure continuity of the pool in case of natural disasters.
Block producer runs in a private subnet making it impossible to directly reach it over the public internet. This prevents various kinds of attacks (such as DDoS) against the most valuable node in our pool.
Docker container images are built from the source code and include a minimal set of vetted tools which minimizes the chance of malware in the container. The images are stored in a private repository to prevent tampering.
Containers are only allowed to run in rootless (unprivileged) mode, making it impossible to install new packages or software on the nodes while they are running. This also prevents privilege escalation in case a node happens to be compromised.
Direct access to the underlying VMs of our Kubernetes cluster is impossible -- even by us.
Direct access to the containers in the cluster is only possible via a secure admin console
Cloud console access is limited to two operators, requiring multi-factor authentication (MFA) to make any modifications to the pool. A seven day delay automatically enforced when conducting any destructive actions (such as deleting VMs)
Regular updates to Kubernetes cluster, VM operating systems, Docker base images, and cardano-node are applied to receive the newest security patches
Firewall prevents non-cardano traffic from reaching all nodes in the pool

Back