Deploy¶
Step-by-step deployments of Authority and Proxy, with the files each one
writes and a verification table. Hosting and component availability are
independent choices: use the HA component procedures with
the selected platform. Each example targets the pilot
profile and says what production adds.
| Scenario | Page | Needs |
|---|---|---|
| Certificates for any scenario: IP address only, Let's Encrypt, your own CA | Certificates | nothing for IP address only; certbot for Let's Encrypt; the CA's root for your own CA |
| Authority and Proxy on one Linux host (a VPS), connectors elsewhere | One Linux host | one host with systemd and a public address; PostgreSQL; a certificate per mode; an OIDC client |
| Authority on an internal host, Proxy in a DMZ | Separate hosts | two hosts with a private route between them; a firewall on the Authority host |
| HA Proxy behind a public LB, HA Authority reached individually | HA with direct Authority failover | Linux binary or Compose; shared PostgreSQL; one L4 LB; private peers; an OIDC client |
| HA Proxy behind a public LB, HA Authority behind a private LB | HA with an Authority load balancer | Linux binary or Compose; shared PostgreSQL; two L4 LBs; private peers; an OIDC client |
| Authority, Proxy and PostgreSQL in Docker Compose | Docker Compose | Docker Engine with Compose v2; the release image; a DNS name and a certificate pair |
| Authority, Proxy and PostgreSQL as Docker Swarm stacks | Docker Swarm | Docker Engine; one node; the release image; a DNS name and a certificate pair |
| Authority and Proxy in Kubernetes, from the Helm chart or the kustomize base | Kubernetes | a cluster with a LoadBalancer implementation; Helm or kubectl; PostgreSQL; a certificate pair |
| One process for development | gdsgate all |
nothing else; dev profile only |
| Changing something after the first start | What a change affects | a running cluster |
Connector routes (direct, tunneled, fronted) decide which ports face the
connectors: route table.
Every scenario needs its inbound ports open before you install. The administrator opens them; each page lists them under "Open the ports".
Verify access¶
Complete the scenario's Verify table first. Then the deployment owner and a client user run these checks on the deployed topology. Agree the test identity, an allowed resource, a denied resource and a harmless operation with the resource and policy owners. Use disposable data for writes. Both resources must exist in the catalog and be served by a connected Connector.
| Check | Expected result | Keep as evidence |
|---|---|---|
| Connect and sign in using the published CA fingerprint or approved certificate trust | Trust verification and login succeed; a wrong CA fingerprint is refused | Client version, Proxy address and verified fingerprint |
| Open the allowed resource with its native client and perform the agreed operation | The operation succeeds through Proxy and Connector | Resource ID, operation, result and time |
| With the same identity, try the denied resource through the gateway | Authorization refuses access; the corresponding audit row records the principal, resource and denial | Matching authorization row and policy revision used for the run |
| From the same client network, try the backend address directly | The connection fails at the network boundary; a backend password error does not prove isolation | Backend address, network error and time |
On Authority, run gdsgate --config "$AUTHORITY_CONFIG" authority audit verify with the configured anchor keys |
Exit 0; both chain and external anchors verify |
Verifier output and exit status |
For container deployments, run the audit command inside the Authority
container with its mounted configuration and keys. The deployment owner
supplies AUTHORITY_CONFIG and the backend address. Follow the
audit integrity procedure
to verify the keys and anchors; a chain-only check does not establish external
anchoring.
Stop on a failed check. An unknown resource, missing Connector or backend error is not a policy-denial result. If direct backend access succeeds, fix the client network boundary and repeat the checks. Preserve audit output on an integrity failure and follow the audit runbook.
Keep the results, versions, topology and test scope with the deployment record in a protected location. Do not include tokens, passwords or private keys. Passing these checks covers this access path; production readiness also needs the backup, recovery and operations procedures.