27be460c07
* onboarding components, routing, steps * onboarding component, toc * fix onboarding mixin * header * refactor docs * fix layout * cleanup routing * docs routing * fix conventions * de en routing * docs, guide contents, nav * rem i18n support * fix routing from docs * rollup onwarn changes, preload * update svelte plugin, update rollup config * move docs * revert img style, remove code table * rem de completely * rollup optim, template * angular quickstart, quickstart overview page, update deps * fix link * pack, slug * prefetch binding, hidden links * export log * guards route ch * fix homepage * angular docs * docs * resolve fsh * overview * docs * docs * packages fix race condition * nav, home link * add vue, aspnet * doc optimizations * embed status pal * angular guide * angular guide * dotnet, angular guide * viewbox * typo * block onboarding route for non iam writers * set links from component data * fix: fetch org context in guard, more main cnt (#1192) * change get started guide, fix code blockquotes, typos * flutter guide * h2 spacing * highlight strong * plus * rm start sublinks * add proxy quickstart * regex * prevent outside click, fix project grant write Co-authored-by: Florian Forster <florian@caos.ch> Co-authored-by: Livio Amstutz <livio.a@gmail.com>
3.0 KiB
| 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 set up for the first time we establish certain default policies 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 consists of logonname and the password hash so that the login process can query that data.
All read models are eventually 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 their 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
Additional infos to the architecture of ZITADEL is located in Architecture Docs
Secret Handling
ZITADEL stores 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 handling are 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