Security set up considerations
This article covers the security considerations you should review before installing Capacity Private Cloud — firewall rules and ingress hostnames for the portals, the cluster encryption hierarchy, and where to find related guidance for certificates and credentials.
Outbound Firewall Rules
The cluster needs outbound access to the following endpoints. Have your security team open these before installation begins:
- Licensing service — https://licensing.lumenvox.com on port 443. Used by deployments to validate license entitlements.
- Public assets bucket — https://lumenvox-public-assets.s3.amazonaws.com/model-files/* on port 443. Used to download platform model files (ASR, TTS, and related artifacts).
If your network blocks general internet egress, ensure both hostnames are added to the allow list. Air-gapped installations require an alternative model-file delivery strategy — contact support if your environment cannot reach the public assets bucket.
Inbound Firewall Rules — Portal Access
The Admin Portal and Deployment Portal are exposed through Kubernetes ingress. Firewall rules and hostname whitelisting using the format ingress_host_name.client_hostname_suffix let your IT team control who can reach them.
Example hostnames:
- admin-portal.testmachine.com
- deployment-portal.testmachine.com
Each portal is exposed on its own configurable port, so you can permit access to the Deployment Portal (used by tenant administrators) without exposing the Admin Portal (used by cluster administrators) on the same network path. See Portals Overview for more on the two portals and how access is typically segregated.
Cluster Encryption Hierarchy
The platform encrypts deployment data using a three-level key hierarchy:
- The Cluster GUID is generated by the cluster administrator and acts as the root encryption value.
- The cluster encryption master key is created the first time the deployment service starts. It is stored in the database, encrypted with the Cluster GUID.
- A customer key is created for each deployment and is encrypted with the cluster master key.
Practical implications:
- The Cluster GUID is the foundation of the entire chain. Anyone with the GUID and a copy of the database can decrypt your deployment data; conversely, restoring a database without the GUID renders the encrypted data unrecoverable.
- Store the GUID in a secrets manager (such as HashiCorp Vault, AWS Secrets Manager, or your organization's equivalent) alongside the rest of your platform credentials. Do not commit it to source control or ticket attachments.
- If you back up the platform database, back up the GUID at the same time and treat them as a paired restore artifact.
TLS Certificates
The portals and platform services are served over HTTPS. In production, use certificates issued by a recognized certificate authority. For development or proof-of-concept environments where self-signed certificates are acceptable, additional steps are required to trust the certificate from your desktop browser — see Configuring Self-Signed Certificates.
Service Credentials
The platform's supporting services (RabbitMQ, PostgreSQL, Redis, MongoDB) authenticate using Kubernetes Secrets that must be applied to the cluster before the Helm chart is installed. See Sample Secrets File for a manifest template and guidance on encoding, applying, and protecting these credentials. As a general rule:
- Do not commit secrets manifests with real credentials to source control.
- Enable encryption at rest for your cluster's etcd if it is not already configured. Without it, the credentials in your Secrets are base64-encoded only — not encrypted — in the underlying datastore.
- Restrict RBAC access to Secrets in the platform namespace to the smallest set of users and service accounts that need them.
Related Articles