search

camunda / camunda-platform-helm

Camunda Platform 8 Self-Managed Helm charts
https://docs.camunda.io/docs/self-managed/overview/
Apache License 2.0
74 stars 137 forks source link

[TASK] Allow to disable components in Identity auth #656

Open aabouzaid opened 1 year ago

aabouzaid commented 1 year ago

Describe the use case:

At the moment, we don't have a mechanism to disable the auth sections in Identity because of the limitation of Helm sub-charts (the sub-charts cannot access each other), which means even if one of the components is disabled (e.g., Connectors), its config is still existing in Identity which confusing especially during the upgrade process (the disabled component password should be preserved even it's not used).

Describe the enhancement/feature:

Un till we have all components in the parent chart (flat structure), introduce a new key global.identity.auth.*.enabled to deal with that limitation (the downside is that the disabled app should be disabled in 2 places, the chart and in the Identity section).

In the future, when we move the rest of the components to the flat chart, we will overcome the downside mentioned above.

Desired outcome and acceptance tests:

Relevant support cases: https://jira.camunda.com/browse/SUPPORT-20659

felix-mueller commented 1 year ago

Related to support: https://jira.camunda.com/browse/SUPPORT-16866

aabouzaid commented 11 months ago

There is a lot of yak shaving in this task, and we still need to enhance the Identity structure; otherwise, it will add more complexity, and it will be harder to tackle in the future (I will try to have those changes as an epic for 8.5 in April).

hisImminence commented 8 months ago

@jessesimpson36 thanks for labelling it with support.

We got pinged on a ETA for the fix. What do you think is reasonable?

There is a lot of yak shaving in this task, and we still need to enhance the Identity structure; otherwise, it will add more complexity, and it will be harder to tackle in the future (I will try to have those changes as an epic for 8.5 in April).

From this I get we should restructure identity first?

jessesimpson36 commented 8 months ago

There is a lot of yak shaving in this task, and we still need to enhance the Identity structure; otherwise, it will add more complexity, and it will be harder to tackle in the future (I will try to have those changes as an epic for 8.5 in April).

I'm personally not sure what is meant by this.

Relating to restructuring identity, identity is a "subchart" which means that it does not have knowledge of which components are enabled or disabled. I think this will increase the difficulty in backporting to previous branches. Initially, I was thinking this was going to be a quick one-line fix for each Secret.

I think the work that needs done is to:

If our focus is just that, I think it could be done without restructuring identity.

As for whether it can get in before 8.5, I'm not sure. Although this task seems small, I'm starting to get anxious about some of the bigger topics like better supporting external elasticsearch.

aabouzaid commented 8 months ago

Once Identity is at the top-level like other components, it will be able to access those component values and can simply disable the values by checking something like optimize.enabled (which is not possible now).

Adding anything to deal with that like extra new keys to control only the secrets will increase the complexity of our chart and more work for the customers as well and it will be even worth it when we want to restructure Identity in the future.

That's why any fix not including restructuring identity will be really bad.