The app deploy Helm chart supports deployment of app + Secrets Provider standalone container

[diverdane]

Is your feature request related to a problem? Please describe.

Issue #238 creates an initial Helm chart and Helm subchart for deploying an application/Summon + authn-k8s sidecar container.

This issue expands on the application deployment main Helm chart by adding a subchart to deploy an application that can make use of a Secrets Provider running as a standalone container.

NOTE: This issue covers only Helm chart implementation. It does not include modification of the app deploy scripts to use this new Helm chart. The modification of the app deploy scripts will be covered in Issue #292. It's entirely possible that it's easier to handle both this issue (Issue #273) and the scripting issue (Issue #292) with a single PR.

This issue will involve using two Helm charts:

1. A new Helm subchart to deploy just the sample application with Summon
2. An existing Secrets Provider Helm chart for deploying the SP as standalone Kubernetes Job (See https://github.com/cyberark/secrets-provider-for-k8s/tree/main/helm/secrets-provider).

There are a couple of options for how to include the existing Secrets Provider Helm chart:

• OPTION 1: Include existing SP Helm chart as a dependency of either the main app deploy Helm chart, or as a dependency of the new app deploy subchart being created for this issue (if it's possible that a Helm subchart can itself have a dependency).
• OPTION 2: Use existing SP Helm chart completely external to new app deploy subchart With this option, the existing SP Helm chart would not be a dependency of either the main app deploy Helm chart or the new app deploy subchart being created.

Describe the solution you would like

• A new Helm subchart is added to the app deployment Helm chart for deploying an application that is capable of using a Secrets Provider running in standalone mode. This needs to include creation of a secrets mapping ConfigMap and also a Kubernetes Secret that contains Conjur variable paths for secrets to be retrieved from Conjur.
• The existing SP Helm chart is included as a chart / subchart dependency if possible.

Describe alternatives you have considered

Additional context

Out of Scope

• Modification to app deploy scripts (this is covered by Issue #292, but a single PR could cover both)
• Creating a values.schema.json for the main Helm chart or the subchart.
• Development of a Helm test for this chart/subchart is not included in this issue.
• Development of a helm-unittest for this chart is not included in this issue.

DoD

• [ ] Helm values.yaml created for app subchart
• [ ] Helm manifest templates created for application w/summon, including secrets mapping ConfigMap
• [ ] New Helm chart or main app deploy Helm chart includes existing SP Helm chart as a dependency, if possible
• [ ] New Helm chart successfully deploys application w/Summon, a secrets mapping ConfigMap, and a Kubernetes Secret

• [ ] New Helm chart is able to use Kubernetes Secrets that have been mutated by the SP running in standalong mode.

  This Helm deployment assumes that the following is already available (not part of this issue):

  • Conjur instance with application policy already loaded
  • Kubernetes cluster prep Helm chart has already been Helm installed
  • Application Namespace prep Helm chart has already been Helm installed
• [ ] Helm chart includes a templates/NOTES.txt that announces app/authenticator has been deployed

[izgeri]

@diverdane is this needed? standalone secrets provider already has a helm chart for deploying - see here

[diverdane]

@izgeri ,

Good question! There are 2 pieces that we need to deploy for this task:

• Secrets Provider standalone Pod
• Sample application (i.e. Pet Store, consuming Kubernetes Secrets that have been updated by Secrets Provider)

The plan is to use the Secrets Provider Helm chart as-is for the first bullet, as you suggested, and to add a subchart to the app deploy Helm chart to do the corresponding sample app (Pet Store) installation.

Cheers! Dane