mirror of
https://github.com/zitadel/zitadel.git
synced 2024-12-14 20:08:02 +00:00
59 lines
2.0 KiB
Markdown
59 lines
2.0 KiB
Markdown
|
---
|
||
|
|
title: System Administration
|
||
|
|
---
|
||
|
|
|
||
|
|
### What is meant by system
|
||
|
|
|
||
|
|
System describes the root of ZITADEL and includes all other elements like organisations, users and so on. Most of the time this part is managed by an user with the role IAM_OWNER.
|
||
|
|
|
||
|
|
### Default Policies
|
||
|
|
|
||
|
|
When ZITADEL is setup for the first time we establish certain default polices for the whole system.
|
||
|
|
|
||
|
|
> TODO Document default policy settings
|
||
|
|
|
||
|
|
### Manage Read Models
|
||
|
|
|
||
|
|
Read Models are a way to normalize data out of the event stream for certain aspects. For example there is a model which consist of logonname and the password hash so that the login process can query that data.
|
||
|
|
|
||
|
|
All read models are eventual consistent by nature and sometimes an administrator would like to verify they are still up-to date.
|
||
|
|
In the ZITADEL Console is a section called administration available where the admin can check all read models and there current state.
|
||
|
|
There is even a possibility to regenerate a read model.
|
||
|
|
|
||
|
|
> When a read model is regenerated it might take up some time to be fully operational again
|
||
|
|
> Depending on the model which is regenerated this might have a operational impact for the end-users
|
||
|
|
|
||
|
|
> Screenshot here
|
||
|
|
|
||
|
|
### Secret Handling
|
||
|
|
|
||
|
|
ZITADEL store secrets always encrypted or hashed in it's storage.
|
||
|
|
Whenever feasible we try to utilize public / private key mechanics to handle secrets.
|
||
|
|
|
||
|
|
**Encryption**
|
||
|
|
We use `AES256` as default mechanic for storing secrets.
|
||
|
|
|
||
|
|
**Password Hashing**
|
||
|
|
By default `bcrypt` is used with a salt of `14`.
|
||
|
|
|
||
|
|
> This mechanic is used for user passwords and client secrets
|
||
|
|
|
||
|
|
**Signing Keys**
|
||
|
|
These keys are randomly generated within ZITADEL and are rotated on a regular basis (e.g all 6h).
|
||
|
|
|
||
|
|
> Signing keys are stored with AES256 encryption
|
||
|
|
|
||
|
|
**TLS**
|
||
|
|
Under normal operations ZITADEL's API nodes are located behind a reverse proxy. So the TLS Key handlings is out of context in this regard.
|
||
|
|
However ZITADEL can use TLS keys at runtime level.
|
||
|
|
|
||
|
|
> TODO Document TLS config
|
||
|
|
|
||
|
|
### IAM Configuration
|
||
|
|
|
||
|
|
> TODO Document ZITADEL config
|
||
|
|
|
||
|
|
### Audit system changes
|
||
|
|
|
||
|
|
> Screenshot here
|