Skip to content

FAQ

Can I manually trigger a secret refresh?

You can trigger a secret refresh by using kubectl or any other kubernetes api client. You just need to change an annotation, label or the spec of the resource:

kubectl annotate es my-es force-sync=$(date +%s) --overwrite

How do I know when my secret was last synced?

The last synchronization timestamp of an ExternalSecret can be retrieved from the field refreshTime. 

kubectl get es my-external-secret -o yaml | grep refreshTime
  refreshTime: "2022-05-21T23:02:47Z"

The interval can be changed by the spec.refreshInterval in the ExternalSecret.

How do I know when the status of my secret changed the last time?

Every ExternalSecret resource contains a status condition that indicates whether a secret was successfully synchronized, along with the timestamp of the last status change of the ExternalSecret (e.g. from SecretSyncedError to SecretSynced). This can be obtained from the field lastTransitionTime:

kubectl get es my-external-secret -o yaml | grep condition -A 5
  conditions:
  - lastTransitionTime: "2022-05-21T21:02:47Z"
    message: Secret was synced
    reason: SecretSynced
    status: "True"
    type: Ready

Differences to csi-secret-store

Please take a look at this issue comment here.

How do I debug an external-secret that doesn't sync?

First, check the status of the ExternalSecret resource using kubectl describe. That displays the status conditions as well as recent events. You should expect a status condition with Type=Ready, Status=True. Further you shouldn't see any events with Type=Warning. Read carefully if they exist.

kubectl describe es my-external-secret
[...]
Status:
  Conditions:
    Last Transition Time:   2022-05-21T21:02:47Z
    Message:                Secret was synced
    Reason:                 SecretSynced
    Status:                 True
    Type:                   Ready
  Refresh Time:             2022-05-21T21:06:47Z
  Synced Resource Version:  1-5c833527afd7ba3f426cb0082ee7e083
Events:
  Type     Reason        Age                  From              Message
  ----     ------        ----                 ----              -------
  Warning  UpdateFailed  4m12s                external-secrets  secrets "yyyyyyy" already exists
  Normal   Updated       12s (x4 over 3m12s)  external-secrets  Updated Secret

If everything looks good you should check the corresponding secret store resource that is referenced from an ExternalSecret. Again, use kubectl describe to show status conditions and events and look for warning signs as described above.

In an ideally, the store should be validated and Ready.

kubectl describe css kubernetes
[...]
Status:
  Conditions:
    Last Transition Time:  2022-05-21T21:02:47Z
    Message:               store validated
    Reason:                Valid
    Status:                True
    Type:                  Ready
Events:
  Type    Reason  Age                From                  Message
  ----    ------  ----               ----                  -------
  Normal  Valid   52s (x4 over 10m)  cluster-secret-store  store validated
  Normal  Valid   52s (x4 over 10m)  cluster-secret-store  store validated

If everything looks normal so far, please go ahead and ensure that the created secret has the expected value. Also, take a look at the logs of the controller.

Upgrading from KES to ESO

Migrating from KES to ESO is quite tricky! There is a tool we built to help users out available here, and there is a small migration procedure.

There are some incompatibilities between KES to ESO, and while the tool tries to cover most of them, some of them will require manual intervention. We recommend to first convert the manifest files, and actually see if the tool provides a warning about any file needed to be changed. Beware that the tool points the SecretStores to use KES Service Account, so you'll also need to tweak that if you plan to uninstall KES after the upgrade.