Maybe implement it in the controller itself (or a helper CLI as e.g.
controller-ctl), e.g. controller ctl reload.

That way we can currently implement it ~crudely via kill -USR1 1, i.e.
"fixing" the CLI interface as ctl reload while leaving space for improvement
should we need it (e.g. adding other verbs than reload, change controlling
interface from signalling to unix socket, etc).

Nice idea. Some practicalities: how would controller ctl reload find the controller pid? Assuming it's pid 1 seems a bit brittle.
Should the controller create a pid file? or a unix domain socket and accept commands through it?

Nice idea. Some practicalities: how would controller ctl reload find the controller pid? Assuming it's pid 1 seems a bit brittle.

Yep, it is - just as we currently have documented it :tada+troll:

Couple thoughts:

• this should be interim~ish only really, as exec -it <pod> is not a
  sustainable/want-able control interface really (more below)
• implementation wise, we could implement it (~ controller ctl reload)
  by doing the equivalent of:

[ $(readlink /proc/1/exe) = $0 ] && kill -USR1 1 || echo "ERROR: pid 1 is not the controller"

i.e. check that pid==1 is running the same executable (path) as me,
to de-brittle that kill it a bit ;)

Should the controller create a pid file? or a unix domain socket and accept commands through it?

I wouldn't move forward that Kube-unfriendly path IMO, we should rather
think on e.g. watching a configMap for changes for a
rotation_time_req: <epoch> field which would need a
rotation_time_last: <epoch> written by the controller for state.

yeah, I'd love a declarative approach.

what if we just had a flag/env:

flag.String("rotate-if-older-than", 0, "rotate the key if there is no secret sealedsecrets.bitnami.com/sealed-secrets-key=active more recent that the given timestamp")

(the we can feed it via a CM, because it's easier to fiddle with kustomize than args I guess)

Can you think of a better name than rotate-if-older-than?

rotation_time_last: written by the controller for state.

do we need that?

We should emit an Event when rotation happens +
the user can see the side effect (kubectl -n kube-system get secret -l sealedsecrets.bitnami.com/sealed-secrets-key=active)

BTW, about: flag.Duration("rotate-period", 0, "New key generation period (automatic rotation disabled if 0)")

// TODO(mkm): implement rotation cadence based on resource times rather than just an in-process timer.

Once we have this we can use the same machinery to check whether to rotate based on absolute cut-off time or period (cut-off time relative to the creation time of the latest active secret)

if we do that, should we just kill the SIGUSR1 feature (no pun intended)

yeah, I'd love a declarative approach.

what if we just had a flag/env:

flag.String("rotate-if-older-than", 0, "rotate the key if there is no secret sealedsecrets.bitnami.com/sealed-secrets-key=active more recent that the given timestamp")

(the we can feed it via a CM, because it's easier to fiddle with kustomize than args I guess)

Can you think of a better name than rotate-if-older-than?

maybe using the well-known TTL acronym for something like
private-key-ttl ? (or maybe add rotation somewhere to make
the action explicit)

rotation_time_last: written by the controller for state.

do we need that?

Missed the fact that we can peek on the priv key timestamp,
thus indeed not needed.

We should emit an Event when rotation happens +
the user can see the side effect (kubectl -n kube-system get secret -l sealedsecrets.bitnami.com/sealed-secrets-key=active)

+1

maybe using the well-known TTL acronym for something like
private-key-ttl ? (or maybe add rotation somewhere to make
the action explicit)

hmm; perhaps it's just me, but isn't TTL more often used to express relative times (basically the equivalent of what we currently call "period"), i.e. for how long are new private keys valid before we replace them with a new one (which would in turn also live for TTL seconds before getting in turn replaced by a new one and so on)?

maybe using the well-known TTL acronym for something like
private-key-ttl ? (or maybe add rotation somewhere to make
the action explicit)

hmm; perhaps it's just me, but isn't TTL more often used to express relative times (basically the equivalent of what we currently call "period"), i.e. for how long are new private keys valid before we replace them with a new one (which would in turn also live for TTL seconds before getting in turn replaced by a new one and so on)?

yup, that was my take: spec'ing it in relative time (rather than fixed epoch~ish),
that way it'd naturally go rotating[...] w/o further instrumentation.

But that's already handled by the rotate-period setting. This issue is specifically about one-off operations

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Due to the lack of activity in the last 7 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.