> For the complete documentation index, see [llms.txt](https://docs.catalyx.solutions/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/architecture/security-and-privacy.md). # Security & Privacy The solution is designed with an emphasis on enterprise-grade security and data privacy, leveraging cloud-native capabilities and established practices in identity management, access control, and cryptographic key protection. ## Authentication and authorisation ### OIDC-based identity management All users and system components authenticate via OpenID Connect (OIDC) using the preferred identity provider — Keycloak by default. The identity provider centrally manages identities, enabling single sign-on and federation with enterprise identity providers. CAT-BM can either **manage** the OIDC clients for a validator itself, or consume clients you have configured in an **external** identity provider. See [Identity Provider Configuration](/catalyx-blockchain-manager/canton-network/version-2.0/installation-instructions-canton/identity-provider-configuration.md). ### Role-based access control CAT-BM enforces access controls based on user roles defined in the user's access token. This includes permission boundaries for deployment operations, audit views, and runtime configuration. Each role — for example Admin, Operator, Auditor — is mapped to a specific set of capabilities within the system. Ledger-level rights are managed separately, on the participant. See [Users & Rights](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/users-and-rights.md). *** ## Infrastructure security ### Cloud environment The reference platform is hosted on a managed Kubernetes service, which provides integrated cloud security features including workload identity, VPC isolation, and encrypted storage. ### Network security * Ingress is controlled using a Kubernetes ingress controller, secured with HTTPS and mutual TLS where applicable. * Internal communication between services within the cluster is protected using Kubernetes network policies, giving fine-grained, pod-level traffic control. For workloads requiring stronger guarantees, a service mesh such as Istio or Linkerd can provide mutual TLS, automatic certificate rotation, and traffic encryption between services. * Kubernetes control plane communication is encrypted in transit between worker nodes and the managed control plane. Private cluster endpoints can be enabled so that Kubernetes API access is limited to internal networks via VPC endpoints or VPN, preventing exposure to the public internet. * DNS traffic inside the cluster is secured through the cluster DNS service, while external service access can be restricted with egress controls including Kubernetes egress policies, NAT gateways, or a network firewall. ### Open source libraries The software components and libraries used by CatalyX Blockchain Manager, and their licences, are listed in [Open Source Licenses](/catalyx-blockchain-manager/canton-network/version-2.0/support-and-resources/open-source-licenses.md). *** ## Key management and external wallets ### Default key storage By default, Canton **node-level operational keys** are generated and stored within the participant's database as part of the standard Canton node configuration. This approach is sufficient for many deployments and aligns with Canton's out-of-the-box security model. ### Advanced security hardening with a KMS For deployments requiring stronger key-protection guarantees, CAT-BM supports a **KMS driver** so that Canton keys are held in an external key management service or HSM. In this model: * Node-level operational keys are generated and stored in a managed KMS or HSM instead of the participant database. * Keys are managed as customer-managed keys. * Private key material is handled by HSM-backed services and never exposed in plaintext. * Deployments can leverage FIPS 140-2 compliant cryptographic modules available in a managed HSM. This enables centralised key management, stronger isolation of cryptographic material, and alignment with enterprise and regulatory security requirements. CAT-BM supports **Azure Key Vault** and **AWS KMS**. See [Key Management Service (KMS)](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/kms-integration.md) for configuration. ### Strict key usage policies * KMS key policies restrict usage exclusively to the workload identities associated with the tenant's Canton workloads. * No human identity is granted direct permission to perform decrypt or sign operations on node operational keys. * All KMS operations are logged by the cloud provider's audit trail, and operational key usage is fully automated and non-interactive. ### Integration with Wallet-as-a-Service providers CAT-BM supports integration with Wallet-as-a-Service (WaaS) providers, enabling secure and compliant management of cryptographic keys without requiring organisations to operate their own key infrastructure. Validators can be registered directly with a WaaS, and wallets for external parties can be created through the WaaS. Instead of handling private keys locally, cryptographic operations such as signing and authentication are delegated to the WaaS, so keys never leave the secure environment. Key storage is managed by the WaaS in a distributed, zero-trust architecture, with an optional configuration to leverage hardware security modules for additional protection and compliance with industry security standards. This approach provides: * **Enhanced security** — private keys are never exposed to application code or infrastructure. * **Operational resilience** — the WaaS provides redundancy, access control, and secure recovery. * **Regulatory compliance** — HSM-backed storage satisfies stringent regulatory and audit requirements. * **Seamless integration** — validators and external parties can be provisioned through the same WaaS API, simplifying lifecycle management. See [Wallet Gateway](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/wallet-gateway.md) for the CAT-BM component that implements this. *** ## Privacy controls ### Data minimisation and auditability Only essential user data is collected and processed. Actions within the system — including deployments, key operations, and access events — are logged and auditable, with logs retained according to enterprise compliance requirements. ### Access logs System access is logged with user context from the identity provider. These logs support compliance with data protection law and enable investigation and traceability in the event of an incident. *** ## Secrets in the console The console never displays secret values. * On the validator **Specification** tab, any field whose path contains `secret`, `password`, `token`, `credential`, `privateKey`, `clientSecret`, or `apiKey` is filtered out entirely, along with the onboarding secret name. * On the **Application** detail page, environment variables sourced from a Kubernetes Secret or another reference are shown with a `from secret` or `from ref` badge in place of the value. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/architecture/security-and-privacy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.