Terraform provider configuration improvement

[nettworker]

Preflight Checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions
• [X] I have joined the ZITADEL chat

Describe your problem

JWT session token has missed at Provider configuration.

Describe your ideal solution

At the moment Zitadel Terraform provider is used jwt_profile_file field for specifying full path to the private key of the service user. How it works well described in documentation - https://zitadel.com/docs/guides/integrate/service-users/private-key-jwt

All works fine when we are staying within Zitadel TF provider scope. If you want to do something outside of TF provider capabilities, you should use JWT token. For example, it may be some specific terracurl request to the Zitadel API.

Today I goes the following way:

1. Generate JWT token as described at the link above and save result to the environment variable such as TF_VAR_ZT_TOKEN.
2. Define TF_VAR_ZT_TOKEN inside of my TF files.
3. Run terraform apply which do all required things with Zitadel API using JWT token.

By my understanding, Zitadel TF provider already convert the jwt private key to the jwt token. Just only one thing is required - publish this value (session jwt token) via specfic Datasource. This datasource can be named as session-token or something like that.

Version

1.2.0

Additional Context

No response

[nettworker]

May be a more straigthtrow idea is add the Terraform function key2jwt to Zitadel TF provider which will return a jwt token like as already implemented in Zitadel tools.

[stebenz]

I'm not quite sure what the full idea is here, but just for my understanding, the issue is that the provider takes a MachineKey and once the 'terraform apply' is run, the provider takes this JWT and creates a token which is used once for the run? And you want to provide the provider directly with a Token instead of the MachineKey and do this action outside of the provider?

[nettworker]

Hi, Stefan!

You are right. My idea was - generate session token inside of TF provider (versus using an external jwt tools/code for this purpose) and use this session token for call Zitadel API directly (for change a human_user password, for example). If i right understand Zitadel position - team has no plans to add "operational" resources to the provider.

I have workaround as Python script for generate JWT token for API access. You can see source code here: https://github.com/yandex-cloud-examples/yc-iam-federation-with-zitadel/blob/main/zitadel-config/ztgen.py

I think that will be great to hide this logic at provider inside - it is remove requirements with any external tools / language libraries.

WBR, /Alexander