Adds poststart hook to delay app startup until SP P2F completes

[diverdane]

Desired Outcome

For the application Helm chart for the Secrets Provider running in Push-to-File mode with secret rotation support, it is desirable that we include:

• A Kubernetes postStart lifecycle hook that delays startup of the application until the SP has finished creating the secret file(s).
• A liveness probe for the application container that forces the application container to be restarted whenever the date of the secrets files change.

Implemented Changes

The following changes are made to the app-secrets-provider-rotation Helm chart in order to delay the application container from starting until after the Secrets Provider sidecar container has finished creating the secret file(s) in the secrets shared volume:

• A 'postStart' lifecycle hook is added to the SP container definition.
• The SP container definition is moved before the app container definition. THe SP container def must appear first in order for the 'postStart' lifecycle hook to take effect before the app container starts.

Also, a liveness probe is added which uses the secret file date to determine if the application should be restarted.

These are being added as a reference for customers who are interested in sequencing the SP sidecar container and their app container startup, and who might need to have their application restarted whenever changes occur in the rendered secret files.

Connected Issue/Story

Resolves #[relevant GitHub issue(s), e.g. 76]

CyberArk internal issue link: [insert issue ID]()

Definition of Done

At least 1 todo must be completed in the sections below for the PR to be merged.

Changelog

• [ ] The CHANGELOG has been updated, or
• [ ] This PR does not include user-facing changes and doesn't require a CHANGELOG update

Test coverage

• [ ] This PR includes new unit and integration tests to go with the code changes, or
• [ ] The changes in this PR do not require tests

Documentation

• [ ] Docs (e.g. READMEs) were updated in this PR
• [ ] A follow-up issue to update official docs has been filed here: [insert issue ID]()
• [ ] This PR does not require updating any documentation

Behavior

• [ ] This PR changes product behavior and has been reviewed by a PO, or
• [ ] These changes are part of a larger initiative that will be reviewed later, or
• [ ] No behavior was changed with this PR

Security

• [ ] Security architect has reviewed the changes in this PR,
• [ ] These changes are part of a larger initiative with a separate security review, or
• [ ] There are no security aspects to these changes

[szh]

Amazing. Looks good except the build is failing.

[imheresamir]

@diverdane This is cool. I was thinking... what if SP wrote out a little shell script with the restart logic for the liveness probe somewhere in the mounted volume so that the app container liveness probe just needed to source it to be able to automatically restart when needed? So instead of an inline script it was just source sp_funcs.sh. That way if they have their own liveness probe script all they have to do is source that script at the top maybe. May not be a good idea, just a thought I had.

[diverdane]

@imheresamir , Hmmm... That's an interesting idea. I was thinking about adding something along those lines, but a little less elegant than what you're proposing. I was thinking about having SP create two sentinel files:

• "secrets-available.txt" : This would only be used by the SP for your postStart trick, so it could be written to the same directory as the client tokens get written to (SP's private emptyDir volume)
• "secrets-updated.txt" : This would be written by SP, and monitored by the app container's livenessProbe. The existence of the file would trigger a container restart.

But adding script(s) would be make it easier to use!

[imheresamir]

A utility script provided by SP could contain the logic for your second point: to check for the existence of the "updated" sentinel. Just trying to think of ways to make it easy for customers to integrate into their existing liveness probe with minimal effort. It could possibly be as simple as a source sp_utils.sh one-liner at the top of their script.