TheArchive/zitadel
1
0
Fork 0
mirror of https://github.com/zitadel/zitadel.git synced 2025-01-05 22:52:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: describe database user credentials handling (#6283)

Browse Source 
* feat: Add full example for helmfile + PostgreSQL

- Adds full helmfile + PostgreSQL example
- Extends production checklist for bullet about insecure credentials
- Extends database documentation to ensure secure user rotation

Refs: https://discord.com/channels/927474939156643850/927866013545025566/1133692721710772294

* chore: revert example and move to zitadel-charts

---------

Co-authored-by: Elio Bischof <elio@zitadel.com>
Co-authored-by: Fabi <fabienne@zitadel.com>
This commit is contained in:
Dominik from Unique 2023-08-02 14:35:13 +02:00 committed by GitHub
parent 4d09409328
commit 4e1dcc0692
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 13 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/docs/self-hosting/manage/database/_postgres.mdx
View File

@ -51,7 +51,7 @@ CREATE DATABASE zitadel;
GRANT CONNECT, CREATE ON DATABASE zitadel TO zitadel;
```
Don't forget to adjust pg_hba.conf and set a password for the zitadel user.
Don't forget to adjust `pg_hba.conf` and set a password for the zitadel user.
With the setup done, follow the [phases guide](/docs/self-hosting/manage/updating_scaling#separating-init-and-setup-from-the-runtime)
to run the init and then setup phase to get all necessary tables and data set up.
to run the init and then setup phase to get all necessary tables and data set up.

11
docs/docs/self-hosting/manage/database/database.mdx
View File

@ -25,4 +25,13 @@ import Postgres from './_postgres.mdx'
<Postgres/>
<More/>
</TabItem>
</Tabs>
</Tabs>
## Zitadel credentials
The [init phase](/docs/self-hosting/manage/updating_scaling#separating-init-and-setup-from-the-runtime) of Zitadel creates a the zitadel user (`Database.*.User.Username` & `Database.*.User.Password`) with their password if it does not exist (and Admin credentials are passed). It is though to note that it does **neither** update **nor** deprecate them. In case you provisioned a Zitadel setup with insecure or _easy-to-guess_ values you should first of all rotate them but also manually ensure, that the old role/user gets deprecated.
If you rotate the credentials you either must opt for a new username or deprecate the old user first (might lead to interruptions) since the init phase will fail if the user already exists but only the password changes. To deprecate the old user you need admin access to your database server and remove the user with commands matching your database provider.
:::caution
Recreating a database will not necessarily remove the user, make sure to check for the user and remove it if necessary.
:::

1
docs/docs/self-hosting/manage/productionchecklist.md
View File

@ -45,6 +45,7 @@ To apply best practices to your production setup we created a step by step check
### Security
- [ ] Ensure that your ZITADEL does not use [the default, example or _easy-to-guess_ credentials](/docs/self-hosting/manage/database#zitadel-credentials)
- [ ] Use a FQDN and a trusted valid certificate for external [TLS](/docs/self-hosting/manage/tls_modes#http2) connections
- [ ] Create service accounts for applications that interact with ZITADEL's APIs
- [ ] Make use of a CDN service to decrease the load for static assets served by ZITADEL