Configure EDB Agent Governance. For deploying the stack, see Installing. For the authentication model and credential handling behind these settings, see Securing access and handling credentials. Once your identity providers and security settings are in place, continue with Connecting data sources.
Managing identity providers
After signing in at publicBaseURL, go to Settings → Identity Providers to manage the identity providers your users sign in through:
Add an OIDC, SAML, or LDAP connector for your organization's identity provider.
After federating, switch day-to-day login away from the bootstrap admin to the federated provider, keeping the bootstrap admin as a break-glass account.
Restrict the admin allowlist to the people who hold administrator access.
Securing your deployment
For credential storage, network protection, and TLS verification requirements, see Securing access and handling credentials. Three points are worth calling out:
- Keep the database volume encrypted at rest, and back it up. It holds instance access keys, cached sessions, and the identity provider connector secrets. Encrypt the underlying volume the same way described in Storing credentials at rest; for how the volume itself is provisioned and sized, see Configuring the Postgres database. If the volume is lost, the databases come back empty — every instance and connector has to be registered again, or restored from a backup you took yourself.
- Registered instances can't reach private network ranges by default. The backend blocks egress to RFC 1918, carrier-grade NAT, and IPv6 unique-local addresses, so a registered instance can't be used to probe your internal network. Set
bff.blockPrivateEgress=false— a Helm value, see Configuration values — only for on-premises deployments whose HM or Loki upstreams live on private addresses. Cloud metadata, loopback, and link-local addresses stay blocked regardless. - Expect a short crash loop right after install. Nothing in the chart holds the stack back until Dex is ready, so the backend may restart a few times until OIDC discovery against
<publicBaseURL>/ssosucceeds. Settingbff.waitForDex=true— see Configuration values — adds an init container that probes the issuer first, turning that crash loop into a clean wait.
Monitoring your deployment
Check pod status across the four containers:
kubectl -n governance get podsWatch nginx's logs for upstream errors — for example a 502 or 504 from bff, which usually means the backend hasn't finished starting or is failing its OIDC discovery check:
kubectl -n governance logs -l governance.io/component=nginx