QTA-10000 - Zitadel System API Access

Statement

This procedure is neither a security leak, issue or backdoor. Granting System API Access to key-authenticated users is a core feature of Zitadel. Having this authentication in place ensures, that the deployment operator (the persona self-hosting the IDP) can always recover the instance even if the instance owners (users or the deployment operator themselves) make potentially fatal (lock-out) configuration mistakes.

Mitigation

The mitigation is actually achievable via the Zitadel Documentation. Unique outlines the high-level procedure again though as it can be critical to restore/keep the control over the instance.

Prerequisites: Clients must have full control over the deployment. Ergo you must be a deployment operator or the infrastructure provider. The procedure can’t be performed by anyone who does not control the deployment of the service.

1. Follow the Access ZITADEL System API guide to create

   1. a key pair

   2. add the key pair to the instance (deployment)

   3. assign a role to the key

      zitadel: configmapConfig: SystemAPIUsers: - my-emergency-user-1: KeyData: <base64 encoded public key .pub> Memberships: - MemberType: System Roles: - "IAM_OWNER"

      This is an example! Make sure you choose your roles carefully for the use cases you want to cover! Refer to the Access ZITADEL System API guide to learn more.
      
      

2. You must create yourself a JWT. This part is not so trivial but Zitadel offers help here as well:

   1. https://github.com/zitadel/zitadel-tools → key2jwt

3. Since we try to update a clientSecret or an IdP in this procedure, depending where the IdP was added there is a two way split:

   1. The IdP was added to the Instance…

      1. https://zitadel.com/docs/apis/resources/admin/admin-service-list-providers

      2. https://zitadel.com/docs/apis/resources/admin/admin-service-update-azure-ad-provider

   2. The IdP was added to an organisation…

      1. https://zitadel.com/docs/apis/resources/admin/admin-service-list-orgs

      2. https://zitadel.com/docs/apis/resources/mgmt/management-service-list-providers

      3. https://zitadel.com/docs/apis/resources/mgmt/management-service-update-azure-ad-provider

4. It goes without saying that the private key from step 1 is stored according to your companies standards.

Impact

There is no downtime expected when following the mitigation. Also the mitigation can be performed anytime.

Not performing the mitigation is also no issue as long as another mean of access/control is present (e.g. username/password/2FA login).