keda: TriggerAuthentication - spec.podIdentity.identityId as a pointer - breaking change in 2.12.0

Report

After upgrading to version 2.12.0, you need to recreate the TriggerAuthentication resource (if you are using PodIdentityProviderAzure \ PodIdentityProviderAzureWorkload with an unspecified identityId). Because the identityId field is a pointer. Otherwise you will get this error “IdentityID of PodIdentity should not be empty”.

Before version 2.12.0 - if you omit the identityId field, your resource will look like this

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  annotations:
    meta.helm.sh/release-name: my-release-name
    meta.helm.sh/release-namespace: my-namespace
  creationTimestamp: xxx
  finalizers:
  - finalizer.keda.sh
  labels:
    app.kubernetes.io/managed-by: Helm
  name: my-name
  namespace: my-namespace
spec:
  podIdentity:
    identityId: ""
    provider: azure-workload

The identityId field is an empty string, although it has been omitted.

The solution is to recreate TriggerAuthentication. This is a breaking change that should at least be pointed out, or should be in version 3.*?

Expected Behavior

Only minor changes

Actual Behavior

Breaking change

Steps to Reproduce the Problem

Use TriggerAuthentication - provider PodIdentityProviderAzure/PodIdentityProviderAzureWorkload and omit the identityId (optional)
Update KEDA to version 2.12.0
You will get this error “IdentityID of PodIdentity should not be empty”

Logs from KEDA operator

No response

KEDA Version

2.12.0

Kubernetes Version

1.26

Platform

Microsoft Azure

Scaler Details

No response

Anything else?

No response

About this issue

Original URL
State: open
Created 8 months ago
Comments: 19 (11 by maintainers)

Most upvoted comments

But, please open the PR to main branch, to the the release/v2.12 branch, we will cherry pick it

JorTurFer on Oct 31, 2023

I think that we should remove validations from operator. IMO, if we are validating the item on create/update, we don’t need to validate it again as on operator. We have introduced admission webhooks, lets use them.

I get the point that forcing users to use the admission is “ugly”, but that’s the goal of the admission webhooks, detecting issues during the admission. If users don’t care about validations, they can remove the webhooks, but it also means that they do need to validate the things from their side, it’s a trade off of their decision. No webhooks? no validations

JorTurFer on Oct 29, 2023

guys, here is fix for a related problem with identityId validation kedacore/charts#553

nice, could you please give an explanation for this change?

If KEDA is deployed using helm, the configuration for the validation webhook is not created (TriggerAuthentication/ClusterTriggerAuthentication). So the identityId validation on the webhook side will not work.

This fix adds the configuration that is needed for TriggerAuthentication/ClusterTriggerAuthentication validation.

radekfojtik on Oct 27, 2023