You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently Zarf agent certificates expire after 375 days. They expire without warning and can often confuse users. There is a builtin way to update certs, zarf tool update-creds agent, but when a users' cert expires, there's not a good way for them to find that command.
We should automatically update the agent creds on init, and warn the user on deploy if their certs are going to expire in the next 60 days.
Describe the behavior you'd like
Given A user has an existing Zarf cluster
When a user runs zarf init
Then the agent certs are updated
and
Given A user has an existing Zarf cluster with an agent cert that is expiring in the next 60 days
When a user runs zarf package deploy
Then a user gets a warning and is told to run zarf tools update-creds (potentially we could roll them automatically here as well)
Describe alternatives you've considered
We could just make the certs last forever. This could be brittle if Kubernetes every enforces a limit on the mutatingwebhook certs. Also not ideal from a security posture perspective
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently Zarf agent certificates expire after 375 days. They expire without warning and can often confuse users. There is a builtin way to update certs,
zarf tool update-creds agent
, but when a users' cert expires, there's not a good way for them to find that command.We should automatically update the agent creds on init, and warn the user on deploy if their certs are going to expire in the next 60 days.
Describe the behavior you'd like
zarf init
and
zarf package deploy
zarf tools update-creds
(potentially we could roll them automatically here as well)Describe alternatives you've considered
We could just make the certs last forever. This could be brittle if Kubernetes every enforces a limit on the mutatingwebhook certs. Also not ideal from a security posture perspective
The text was updated successfully, but these errors were encountered: