3.5 KiB
title | geekdocDescription | weight |
---|---|---|
Internal Services | Documentation for Non-public applications | 30 |
This page provides some documenation on other services used within burble.dn42 that are not directly available for public use.
rproxy.burble.dn42
Core nodes run an nginx container that acts as a reverse proxy for services hosted in tier2.
The reverse proxy is distributed to improve local response times and is anycast as rproxy.burble.dn42. Most web services provided by burble.dn42 are simply CNAMEs to the reverse proxy which then balances and forwards the request to the actual service.
As well as a reverse proxy, nginx also provides:
- TLS termination
- A local page cache to act as a poor man's CDN
- Static content server
n8n.burble.dn42
n8n is used to provide an automation and workflow service.
As an example, n8n is used to update dn42regsrv and [ROA tables](/services/public#ROA Tables) when the registry changes.
vault.burble.dn42
Hashicorp Vault is used to handle secrets
across the burble.dn42 network.
Vault is deployed as a 3 node cluster across the Europe core nodes
and uses Consul as the cluster back end.
TLS Certificate Authority
Vault acts as the main certificate authority for burble.dn42 PKI, however there is also an intermediate ACME server based on smallstep CA.
Vault allows for regular, automated renewal of certificates on short timeframes (typically a rolling week or monthly basis).
SSH Certificate Authority
Vault also acts as an SSH certificate authority, verifying both users and servers within the network.
Server certificates are generated during deployment, whilst user (or role) certificates are short lived and generated on demand.
Deployment Secrets
Vault holds secrets used during node and service deployments.
Most burble.dn42 are built as stateless container images and secrets are pushed from vault in to the live containers at runtime. This ensures the container images do not contain secrets and that secrets can be applied per instance even when using a common image.
Vault also manages database credentials (using the mysql/mariadb integration), and these are also automatically generated and pushed in to container instances on deployment.
The authority to access deployment secrets is inherited, on demand, from the user token during the deployment process. This ensures that even if access was gained to the deployment server, secrets could still not be accessed without also having access to a live user token.
ci.burble.dn42
The burble.dn42 git has an associated CI/CD service based on drone.
The CI/CD service is used to manage DNS, build and publish applications and the burble.dn42 website.
minio.burble.dn42
min.io is used as an S3 compatible block storage service. For example, min.io is used for storing build artifacts from CI pipelines.
As well as a central storage server, min.io is deployed in 'gateway' mode to provide local, regional caches for the block storage.
The min.io services uses a global etcd cluster for credential management.
lounge.burble.dn42
For lurking on #dn42 I use thelounge, a web based IRC client.