Remove Secret migration workaround

[dervoeti]

Follow up issue for #453

This workaround should only be needed when migrating from SDP 24.3 to 24.7.
It probably won't hurt to keep the Job that copies over the Secret, since it checks if it's already there and only copies it if it's not present. But if we require customers to incrementally upgrade SDP (e.g. no jump from 24.3 to 24.11 possible), then we can remove this workaround (revert #476) in 24.11 to reduce complexity, since it's guaranteed that the Job will have run when upgrading to 24.7.

[lfrancke]

I think I'll wait another release or two with this. We don't officially support skipping a release but we do know that people are doing it.

[siegfriedweber]

Unfortunately, it is not possible to disable the deployment of this Job on newly created clusters. This forces customers to mirror the tools image which contains CVEs.

It is also not obvious that they have to mirror the image tagged with 24.7.0 for the SDP 24.11.0:
https://github.com/stackabletech/secret-operator/blob/24.11.0/deploy/helm/secret-operator/templates/secret_migration_job.yaml#L33

[lfrancke]

I'm not entirely sure I understand the implications of that Sigi. Could you elaborate?

[siegfriedweber]

I'm not entirely sure I understand the implications of that Sigi. Could you elaborate?

In https://github.com/stackabletech/secret-operator/pull/476/files, a Job was added to the Helm chart to migrate the TLS CA keypair from the hard-coded default namespace to the operator namespace.

If the secret operator is installed via Helm, then the following Job is also deployed:

apiVersion: batch/v1
kind: Job
metadata:
  name: secret-operator-secret-migration
spec:
  template:
    spec:
      containers:
      - name: migrate-secret
        image: docker.stackable.tech/stackable/tools:1.0.0-stackable24.7.0
...

When installing the SDP on a new cluster, this Job is unnecessary. Unfortunately, it is not possible to disable the Job creation via Helm values:

$ helm show values \
      --repo https://repo.stackable.tech/repository/helm-stable \
      --version 24.11 \
      secret-operator
...
secretMigrationJob:
  image:
    repository: docker.stackable.tech/stackable/tools
    pullPolicy: IfNotPresent
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 100m
      memory: 128Mi
...

It is possible to change the repository of the image, but the tag 1.0.0-stackable24.7.0 is hard-coded (https://github.com/stackabletech/secret-operator/blob/24.11.0/deploy/helm/secret-operator/templates/secret_migration_job.yaml#L33).

The image docker.stackable.tech/stackable/tools:1.0.0-stackable24.7.0 is old and contains several CVEs:

$ docker run \
      --rm \
      neuvector/scanner \
      -i docker.stackable.tech/stackable/tools:1.0.0-stackable24.7.0
common.LoadCveDb: Expand new DB - version=3.641
Image: https://docker.stackable.tech/stackable/tools:1.0.0-stackable24.7.0
Base OS: rhel:9.4
Created at: 2024-07-24T07:27:33Z

Vulnerabilities: 53, HIGH: 13, MEDIUM: 33, LOW: 7, UNKNOWN: 0
...

For this reason, some customers do not want to mirror this image, especially because it is useless.

The workaround is, to download the Helm chart, unpack it, remove the files for the secret migration manually, pack it and install this custom Helm chart.

If we postpone the removal of this secret migration workaround, then I would propose to

1. make it possible to switch it off via Helm values and
2. allow the configuration of the image tag in the Helm values.

[razvan]

For this reason, some customers do not want to mirror this image, especially because it is useless.

Just a side note that OLM uses this image too and there is no way to remove it because it's also used for actually installing the secret op.

Also the job cannot be disabled on OLM either. We can only remove it completely in the next OLM version.

[lfrancke]

Understood. I think it's fine for us to remove this in 25.3 but you are making a good argument to already remove it in 24.11.1.
Do you see a problem with that?

I'm not entirely sure if I understand the OLM implications though.