boxboat / dockhand-secrets-operator Goto Github PK

Helm currently doesn't allow customization of Kind sorting. Update DockhandSecret and DockhandSecretsProfile to Secret and Profile

• Change apiVersion from dockhand.boxboat.io to dhs.dockhand.dev
• Change kind: DockhandSecret to Secret
• Change kind: DockhandSecretsProfile to Profile
• Change Label dockhand.boxboat.io/autoUpdate to dhs.dockhand.dev/autoUpdate
• Change internal annotations from dockhand.boxboat.io to dhs.dockhand.dev

Deprecation version: v1alpha1 DockhandProfile

• version: dockhand.boxboat.io/v1alpha1 -> version: dhs.dockhand.dev/v1alpha2
• kind: DockhandProfile -> kind: Profile

Deprecation version: v1alpha1 DockhandSecret

• version: dockhand.boxboat.io/v1alpha1 -> version: dhs.dockhand.dev/v1alpha2
• kind: DockhandSecret -> kind: Secret
• profile: <profile-name> -> profile.name: <profile-name> profile.namespace: <profile-namespace>
  • profile field is now an object that contains a name and namespace field.
  • v1alpha1 assumed DockhandProfiles existed in dockhand-secrets-operator namespace and did not support multi-tenant use case. v1alpha2 allows the operator to operate in a multi-tenant mode or a single tenant mode where Profiles can be referenced in any namespace where the dockhand-secrets-operator has read access.

The motivation for this change is ensure that the helm Kind sorter creates a secret.dhs.dockhand.dev before attempting to create Deployments, StatefulSets or DaemonSets. This will prevent an unnecessary rollover when using the autoUpdate label. Previous dockhand.boxboat.io/autoUpdate will also continue to be supported until the next major release.

See kind_sorter and open issue to allow custom sorting.

Currently DockhandProfile is assumed to be in the same namespace as the operator and any namespace can reference the profile. With the CRD changes to Profile make the profile truly namespace scoped supporting multi-tenant use case by default. For situations where single tenant use is desirable add a flag to allow cross namespace access

Hey!

Great project!

We are working on a similar project and maybe we should merge efforts on a single project? https://github.com/external-secrets/external-secrets

We chat on #external-secrets channel on kubernetes slack, and we have community meetings every other Wednesday and you are very welcome to join!

This is a project that already is the merged efforts of some other initiatives, the most popular one being KES (Kubernetes External Secrets from Godaddy, which will be deprecated in favor of the newer ESO).

Let me know what you think!

Currently events are showing that the managed secret has been updated multiple times, when in reality it is created and then not changed unless the backend secret data changes or the Dockhand Secret changes. The controller should check the ResourceVersion when updating the underlying Secret

Currently the dockhand-secrets-operator supports automatic updates of a deployment through the use of a label but the autoUpdate only occurs when the secret CRD has been modified in some way. Add a polling option that makes autoUpdate scrape the secrets backend at a configurable interval to support automatic re-deployment if the secret is modified on the backend - without requiring a modification to the secret CRD.

metadata:
  labels:
    dhs.dockhand.dev/autoUpdate: "true"

Initial operator uses k8s.io/api/certificates/v1beta1 which is deprecated update to use k8s.io/api/certificates/v1

Vault role does not set auth option correctly

Issue with vault token based auth - parameters set incorrectly when using token based authorization

Add events to DockandSecret and retry failed secrets

Add the ability to create different types of secrets from a DockhandSecret, currently only type: Opaque secrets are created.

Remove v1alpha1 CustomResourceDefintion and types

Build arm64 versions

If you install the dockhand-secrets-operator chart, delete and reinstall then you will end up in a bad cert state for the webhook. This is because the logic for creating the self signed webhook cert does not check to see if the cert is valid against the CA currently part of the MutatingWebhookConfiguration. The cert from the first installation is still valid datewise but no longer has the self signed CA that was used to create it in the MutatingWebhookConfiguration. The webhook should store the CA.crt in the TLS secret and update the MutatingWebhookConfiguration with that certificate. When cert renewal occurs it will roll the CA and the cert.

Add status to the DockhandSecrets CRD to allow users to see the state of a DockhandSecret and troubleshoot if necessary

Webhook discovers secrets referenced by the pod.spec.containers.env[] and pod.spec.Volumes[] but does not currently discover a secret name if you use pod.spec.containers.envSource[].

When you change a secret.dhs.dockhand.dev annotation it does not force a generation update - which means that the controller will not attempt to update the managed secret. Remove the observedResourceVersion field which changes with every write to the object and add an annotation checksum to ensure that annotation changes result in a refresh of the managed secret.

dockhand-secrets-operator uses rancher/wrangler to write the Dockhand Secret controller. The on change controller is periodically executed and currently the controller.onDockhandSecretChange method will query the secrets manager backends each time. The controller should store an observedGeneration field in the State and only query the Secrets Manager if the metadata.generation does not match the observedGeneration

Currently the dockhand-secrets-operator controller assumes the secrets for a Profile are located in the same namespace as the operator, it should use the namespace of the Profile.

Retry backoff logic for obtaining a certificate could run forever if not successful after 10 tries

The controller logic does not handle the case where a Profile is edited or deleted properly. Currently the only way to force the controller to pickup the change is to restart the controller, because the profile is cached. Add logic to invalidate the cached profile when there is a change or deletion to a Profile

Latest updates in 0.5.0 will prevent the controller from re-creating a managed secret if a third party (user) deletes the manger secret.

Currently the multi-tenancy option is not checked when a user specifies a profile that is in a different namespace than the profile.

Vault authorization is not working properly