Production checklist

This page helps you check a deployment before people start signing in to it.

Each item links to the page that explains it. A deployment the setup wizard generated already meets several of them, but check them all anyway: a file edited by hand can undo any of them.

Secrets

• The AES key is backed up, apart from the database backups. Without it, a restored database decrypts nothing. See Back up the AES key.
• Every secret is your own, generated for this deployment and never copied from an example. See What each secret protects.
• The secrets are readable only by what needs them: out of version control and shared directories. See Where your setup keeps them.
• The administrator’s password is strong, at least 15 characters. Changing GOIABADA_ADMIN_PASSWORD after the first start does nothing; see The admin password.
• The administrator has two-factor authentication, set up from their account in the admin console.

Network

• Both public URLs are https://. GOIABADA_AUTHSERVER_BASEURL and GOIABADA_ADMINCONSOLE_BASEURL decide whether each server marks its cookies Secure, and there’s no other setting for it. See URLs and listeners.
• Only your proxy reaches ports 9090 and 9091. Publish 443, and 80 if you redirect it, and nothing else.
• The metrics ports, 9190 and 9191, are published nowhere. Only your scraper reaches them. See Monitoring.
• Forwarded headers are trusted only from your proxy. Turn on GOIABADA_AUTHSERVER_TRUST_PROXY_HEADERS and GOIABADA_ADMINCONSOLE_TRUST_PROXY_HEADERS only behind a proxy, and list your proxies in GOIABADA_AUTHSERVER_TRUSTED_PROXIES and GOIABADA_ADMINCONSOLE_TRUSTED_PROXIES when there’s more than one hop. Turned on without a proxy, anyone can choose the address Goiabada rate limits and audits them under; behind a second hop with no list, everyone shares the outer proxy’s address. See Client IP and proxy trust.
• Certificates renew themselves, whatever issues them.

The hop from the admin console to the auth server

• The admin console reaches the auth server over a network you trust. With an http internal URL, the hop is plain HTTP, and it carries the admin console’s client secret, its refresh token and administrators’ tokens.

The internal hop isn't encrypted

The Docker Compose files and Kubernetes manifests the setup wizard generates set GOIABADA_AUTHSERVER_INTERNALBASEURL to a plain HTTP address. That’s sound on a network only your deployment uses, such as a Docker Compose network or a cluster’s pod network. When it isn’t, encrypt the hop: a network plugin that encrypts pod traffic, a service mesh with mutual TLS, or an https:// internal URL to the auth server’s own HTTPS listener on port 9443, whose certificate names the host the admin console calls. The admin console trusts the system’s certificate authorities, and also the ones SSL_CERT_FILE or SSL_CERT_DIR names. Set both, and they replace the system’s. See Docker Compose or Kubernetes for the steps.

Database

• The auth server checks whose database it reached, with GOIABADA_DB_TLS_MODE set to verify-full. If the system doesn’t trust the authority that signed the database’s certificate, GOIABADA_DB_TLS_CA_FILE names it. Without verify-full, the database sits where nobody else can read its traffic: on the auth server’s host, or on a private network only the auth server and your administrators reach.

By default, the database server isn't checked

Never use disable, prefer or require across a network you don’t trust. They check no certificate, and prefer is the default.

With GOIABADA_DB_TLS_MODE unset, Goiabada encrypts its connection to PostgreSQL and MySQL when the server offers TLS, and falls back to plain text when it doesn’t. On SQL Server it encrypts the login, and the rest of the session only when the server forces encryption. It checks no certificate, and warns at every start. See Where the database sits.

• The database login has rights in Goiabada’s database and nowhere else. See Create the database yourself.
• The database is backed up, and you’ve restored a backup at least once, with the AES key it was taken under.
• One auth server, if you use SQLite. SQLite is a file on one host, used through one connection. For several instances, use PostgreSQL, MySQL or SQL Server. See Database.

Abuse

• The rate limiter is on, GOIABADA_AUTHSERVER_RATELIMITER_ENABLED=true. The limits counted by a user or an email, 100 wrong passwords an hour for one account among them, apply either way, and it adds the limits counted by an IP address, on password sign-in among them. The setup wizard asks. See Rate limits.

Monitoring and logs

• Something checks /health on both servers. It says the process is up, not that the database or the auth server answers.
• Both servers’ metrics are scraped. See Monitoring.
• Alerts fire at least on server errors, database pool waits, rate-limit refusals and the cleanup run. See Set up alerts.
• Both servers’ logs are collected, standard error included, with request logging on. See Collect the logs.
• The audit log goes where you need it, for as long as you need it. New installations write it to the logs and the database and keep it 180 days; change that on the Audit log settings page. See Audit log.

After it’s live

• Sign in to the admin console, with the administrator’s account.
• Add sign-in to a test client and run its whole flow, from the sign-in page to the token.
• Write down how the deployment is configured, where its secrets are kept, and how it’s backed up.

Next steps

SecretsWhat each secret protects, and backing up the AES key.

MonitoringTurn on the metrics, scrape them and set up alerts.

Upgrade GoiabadaMove to a new release, and back again.