Update dependency external-secrets/external-secrets to v0.18.0

Sylva Renovate botrequested to merge
renovate/external-secrets-external-secrets-0.x into main

This MR contains the following updates:

Package Type Update Change
external-secrets/external-secrets Kustomization minor v0.10.7 -> v0.18.0

Release Notes

external-secrets/external-secrets (external-secrets/external-secrets)

v0.18.0

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.18.0 NOTE - the following UBI images are not currently working (broken build process). Image: ghcr.io/external-secrets/external-secrets:v0.18.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.18.0-ubi-boringssl

Potential Breaking Changes

This version includes a massive refactor of the AWS providers. Now, they are finally using V2 and thus opened some regions and are more maintainable. Massive thanks goes to @​Ilhan-Personal for this work. We really appreciate all the effort that went into this. Thank you!

Further update has been done to 1Password provider SDK. Now, GetSecretMap functions the same way as 1Password connect. Which is that it uses extract to filter for files or other values.

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.17.0...v0.18.0

v0.17.0

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.17.0 Image: ghcr.io/external-secrets/external-secrets:v0.17.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.17.0-ubi-boringssl

BREAKING CHANGE

v0.17.0 Stops serving v1beta1 apis. You need to update your manifests from v1beta1 to v1 prior to updating from v0.16 to v0.17.

The only change needed is upgrading your manifests to v1 (i.e. removing the beta1 from v1beta1).

Be sure to do that to all your manifests prior to bumping to v0.17.0! v0.16.2 already supports v1 so this process should be smooth.

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.16.2...v0.17.0

v0.16.2

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.16.2 Image: ghcr.io/external-secrets/external-secrets:v0.16.2-ubi Image: ghcr.io/external-secrets/external-secrets:v0.16.2-ubi-boringssl

BREAKING CHANGE

When updating to v0.16.2, if you leverage Generators with refreshInterval: 0 or any refreshPolicy to not update it, this version WILL FORCE THAT VALUE TO BE UPDATED.

Apologies to the user base, we did not expect this breaking change behavior out of these contributions. 🙇 🙏

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.16.1...v0.16.2

v0.16.1

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.16.1 Image: ghcr.io/external-secrets/external-secrets:v0.16.1-ubi Image: ghcr.io/external-secrets/external-secrets:v0.16.1-ubi-boringssl

What's Changed

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.16.0...v0.16.1

Guide to Promoting to 0.16

Pre Upgrade checks

Make sure you are not using any v1alpha1 resources across all of your infrastructure.

You can do that by performing manual inspection on your manifests, tooling, etc.

Make sure there are no storedVersions on v1alpha1 for externalsecrets, clusterexternalsecrets, secretstores and clustersecretstores crds:

Run the following command:

kubectl get crd \
    externalsecrets.external-secrets.io\
    secretstores.external-secrets.io\
    clustersecretstores.external-secrets.io\
    clusterexternalsecrets.external-secrets.io\
    -o jsonpath='{.items[*].status.storedVersions[?(@​=="v1alpha1")]}' | \
    grep -q v1alpha1 && echo "NOT SAFE! REMOVE v1alpha1 FROM YOUR STORED VERSIONS" || echo "Safe to Continue"

If that command returns not safe, remove v1alpha1 from your stored versions. Make sure this status is persisted after you verify these commands.

kubectl patch --subresource=status crd externalsecrets.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]' 
kubectl patch --subresource=status crd secretstores.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]' 
kubectl patch --subresource=status crd clusterexternalsecrets.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]' 
kubectl patch --subresource=status crd clustersecretstores.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]'

Upgrading

CRDs as part of external-secrets installation

If you're installing external-secrets CRDs with helm (installCRDs=true - the default), all you need to do is

helm repo update
helm upgrade <your_app_name> external-secrets/external-secrets --version 0.16.1

The same goes if you're using argocd or flux and managing crds directly with helm. The above should just work.

CRDs installed separately

If CRDs are installed separately, the first step you need to do is bump the crds:

kubectl apply -f https://raw.githubusercontent.com/external-secrets/external-secrets/v0.16.1/deploy/crds/bundle.yaml

Verify no error occurs. After that, you can freely migrate external-secrets to v0.16.1.

Troubleshooting

conversion webhook for external-secrets.io/v1, Kind=ExternalSecret failed: the server could not find the requested resource

Root cause: the CRD installation process failed. Double check your CRD installation process finished successfully

v0.16.0

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.16.0 Image: ghcr.io/external-secrets/external-secrets:v0.16.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.16.0-ubi-boringssl

!!! warning it is known v0.16.0 will not be an easy upgrade if you're not consuming from our official sources via helm. we are improving the upgrade path for users depending on kustomize in 0.16.1. Please be patient :)

Guide to Promoting to 0.16

Pre Upgrade checks

Make sure you are not using any v1alpha1 resources across all of your infrastructure.

You can do that by performing manual inspection on your manifests, tooling, etc.

Make sure there are no storedVersions on v1alpha1 for externalsecrets, clusterexternalsecrets, secretstores and clustersecretstores crds:

Run the following command:

kubectl get crd \
    externalsecrets.external-secrets.io\
    secretstores.external-secrets.io\
    clustersecretstores.external-secrets.io\
    clusterexternalsecrets.external-secrets.io\
    -o jsonpath='{.items[*].status.storedVersions[?(@&#8203;=="valpha1")]}' | \
    grep -q v1alpha1 && echo "NOT SAFE! REMOVE v1alpha1 FROM YOUR STORED VERSIONS" || echo "Safe to Continue"

If that command returns not safe, remove v1alpha1 from your stored versions. Make sure this status is persisted after you verify these commands.

kubectl patch --subresource=status crd externalsecrets.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]' 
kubectl patch --subresource=status crd secretstores.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]' 
kubectl patch --subresource=status crd clusterexternalsecrets.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]' 
kubectl patch --subresource=status crd clustersecretstores.external-secrets.io --type=json -p='[{"op": "replace", "path": "/status/storedVersions", "value": ["v1", "v1beta1"]}]'

Upgrading

CRDs as part of external-secrets installation

If you're installing external-secrets CRDs with helm (installCRDs=true - the default), all you need to do is

helm repo update
helm upgrade <your_app_name> external-secrets/external-secrets --version 0.16.1

The same goes if you're using argocd or flux and managing crds directly with helm. The above should just work.

CRDs installed separately

If CRDs are installed separately, the first step you need to do is bump the crds:

kubectl apply -f https://raw.githubusercontent.com/external-secrets/external-secrets/v0.16.1/deploy/crds/bundle.yaml

Verify no error occurs. After that, you can freely migrate external-secrets to v0.16.1.

Troubleshooting

conversion webhook for external-secrets.io/v1, Kind=ExternalSecret failed: the server could not find the requested resource

Root cause: the CRD installation process failed. Double check your CRD installation process finished successfully

spec.conversion.webhookClientConfig: Forbidden: should not be set when strategy is not set to Webhook

Use 0.16.1 as opposed to 0.16.0 on your installation path. That should be fixed on this release

My issue is not here What do I do?

Add a message to https://github.com/external-secrets/external-secrets/issues/4662

BREAKING CHANGES

This release introduces quite a few breaking changes, including:

  • Removal of Conversion Webhooks and SecretStore/v1alpha1, ExternalSecret/v1alpha1 and their cluster counterparts
  • Promotion of ExternalSecret/v1 and SecretStore/v1 and their cluster counterparts
  • Removal of v1 templating engine
  • Removal of ValueMaps from Fake Secret Store

if you have any issues during your upgrade, please check https://github.com/external-secrets/external-secrets/issues/4662

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.15.1...v0.16.0

v0.15.1

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.15.1 Image: ghcr.io/external-secrets/external-secrets:v0.15.1-ubi Image: ghcr.io/external-secrets/external-secrets:v0.15.1-ubi-boringssl

v0.15.0

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.15.0 Image: ghcr.io/external-secrets/external-secrets:v0.15.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.15.0-ubi-boringssl

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.14.4...v0.15.0

v0.14.4

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.14.4 Image: ghcr.io/external-secrets/external-secrets:v0.14.4-ubi Image: ghcr.io/external-secrets/external-secrets:v0.14.4-ubi-boringssl

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.14.3...v0.14.4

v0.14.3

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.14.3 Image: ghcr.io/external-secrets/external-secrets:v0.14.3-ubi Image: ghcr.io/external-secrets/external-secrets:v0.14.3-ubi-boringssl

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.14.2...v0.14.3

v0.14.2

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.14.2 Image: ghcr.io/external-secrets/external-secrets:v0.14.2-ubi Image: ghcr.io/external-secrets/external-secrets:v0.14.2-ubi-boringssl

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.14.1...v0.14.2

v0.14.1

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.14.1 Image: ghcr.io/external-secrets/external-secrets:v0.14.1-ubi Image: ghcr.io/external-secrets/external-secrets:v0.14.1-ubi-boringssl

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.14.0...v0.14.1

v0.14.0

Compare Source

Potential Breaking Change

Stateful Generators have been introduced with:

While normally this isn't a problem, external secrets controller and push secrets controller have been changed.

If any normal operation that should work encounters a problem, please don't hesitate to open an issue. Please also include that the problem appeared after switching to this version. Thank you!

Image: ghcr.io/external-secrets/external-secrets:v0.14.0 Image: ghcr.io/external-secrets/external-secrets:v0.14.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.14.0-ubi-boringssl

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.13.0...v0.14.0

v0.13.0

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.13.0 Image: ghcr.io/external-secrets/external-secrets:v0.13.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.13.0-ubi-boringssl

BREAKING CHANGES

https://github.com/external-secrets/external-secrets/pull/4262 introduces a breaking change in the METADATA structure for the AWS PARAMETER STORE.

The old metadata structure changed to this new structure described here: https://external-secrets.io/latest/provider/aws-parameter-store/#additional-metadata-for-pushsecret

It looks like this:

metadata:
        apiVersion: kubernetes.external-secrets.io/v1alpha1
        kind: PushSecretMetadata
        spec:
          secretType: SecureString
          kmsKeyID: bb123123-b2b0-4f60-ac3a-44a13f0e6b6c
          tier:
            type: Advanced # default is Standard
            policies:
              - type: "Expiration"
                version: "1.0"
                attributes:
                  timestamp: "2024-12-02T21:34:33.000Z"
              - type: "ExpirationNotification"
                version: "1.0"
                attributes:
                  before: "2"
                  unit: "Days"
              - type: "ExpirationNotification"
                version: "1.0"
                attributes:
                  before: "30"
                  unit: "Days"
              - type: "NoChangeNotification"
                version: "1.0"
                attributes:
                  after: "30"
                  unit: "Days"

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.12.1...v0.13.0

v0.12.1

Compare Source

RELEASE VERSION

My apologies, when creating the release, 0.12.0 failed. The branch and tag however, have been created and I was unable to delete them. Thus, the version has been increased to 0.12.1 after the fix and now that's the current version. I hand updated the release notes to include everyone into the changes.

BREAKING CHANGES

The following breaking changes have been introduced into this release:

  • Permission update for AWS provider adding BulkFetch when getting multiple secrets ( significant API reduce but comes with adding a permission for bulk endpoint )
  • fixed a typo for a generator in the json tag where before it was ecrRAuthorizationTokenSpec with an extra R
  • We standardized the GCP Secrets Manager Metadata structure for PushSecrets ( be aware that existing manifests will stop working until updated to the standardized version ) for more info see https://github.com/external-secrets/external-secrets/pull/4210

Images

Image: ghcr.io/external-secrets/external-secrets:v0.12.1 Image: ghcr.io/external-secrets/external-secrets:v0.12.1-ubi Image: ghcr.io/external-secrets/external-secrets:v0.12.1-ubi-boringssl

What's Changed

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.11.0...v0.12.1

v0.12.0

Compare Source

Image: ghcr.io/external-secrets/external-secrets:v0.12.0 Image: ghcr.io/external-secrets/external-secrets:v0.12.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.12.0-ubi-boringssl

v0.11.0

Compare Source

Deprecation of OLM Releases

As of 0.11.0 is the last release available for OLM until further notice. Depending on the way this goes, we might still have OLM support (ideally with a properly built operator for that), but for sure in a different support scheme as to not overload maintainers anymore. Also a valid note - you can still use 0.11.0 OLM release and the newest ESO images, you just need to set image.tag appropriately in your setup.

Kubernetes API load and significant decrease

A new way of reconciling external secrets has been added with pull request #​4086.

This significantly reduces the number of API calls that we make to the kubernetes API server.

  1. Memory usage might increase if you are not already using --enable-secrets-caching
    1. If you are using --enable-secrets-caching and want to decrease memory usage at the expense of slightly higher API usage, you can disable it and only enable --enable-managed-secrets-caching (which is the new default)
  2. In ALL cases (even when CreationPolicy is Merge), if a data key in the target Secret was created by the ExternalSecret, and it no longer exists in the template (or data/dataFrom), it will be removed from the target secret:
    1. This might cause some peoples secrets to be "cleaned of data keys" when updating to 0.11.
    2. Previously, the behaviour was undefined, and confusing because it was sort of broken when the template feature was added.
    3. The one exception is that ALL the data suddenly becomes empty and the DeletionPolicy is retain, in which case we will not even report and error, just change the SecretSynced message to explain that the secret was retained.
  3. When CreationPolicy is Owner, we now will NEVER retain any keys and fully calculate the "desired state" of the target secret each loop:
    1. This means that some peoples secrets might have keys removed when updating to 0.11.

Generators and ClusterGenerator

We added ClusterGenerators and Generator caching as well. This might create some problems in the way generators are defined now.

CRD Admission Restrictions

All of the CRDs now have proper kubebuilder markers for validation. This might surprise someone leaving out some data that was essentially actually required or expected in a certain format. This is now validated in #​4104.

Images

Image: ghcr.io/external-secrets/external-secrets:v0.11.0 Image: ghcr.io/external-secrets/external-secrets:v0.11.0-ubi Image: ghcr.io/external-secrets/external-secrets:v0.11.0-ubi-boringssl

What's Changed

New Contributors

Full Changelog: https://github.com/external-secrets/external-secrets/compare/v0.10.7...v0.11.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

  • If you want to rebase/retry this MR, check this box

This MR has been generated by Renovate Bot.

Edited by Sylva Renovate bot

Merge request reports