There is an initial framework for the Namespace prep Helm test

[diverdane]

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

After a Kubernetes administrator has run helm install ... or helm upgrade ... using the Namespace prep Helm chart, we would like to provide a way for the admin to validate the Helm release, i.e. to prove that the Kubernetes objects that have been deployed can be trusted to support the deployment of applications that will use the associated authn-k8s authenticator.

Describe the solution you would like

This will require the implementation of a Helm test (see Helm test documentation) that can be run on-demand by the Kubernetes administrator after helm install ... and helm upgrade ....

The Helm test for this Helm chart can be largely ported from the Helm test that was created for the
Kubernetes cluster prep Helm chart (See Issue #229).

Helm tests typically use the deployment of Kubernetes Pods or Jobs to run custom test applications to exercise the functionality of the Release that they're designed to test.

For the Namespace prep Helm chart, the Helm test will refer to the data in the Conjur Connect ConfigMap (using a Pod volume mount), and will use curl and openssl to access the configured Conjur instance (based on Conjur URL) to validate that the configuration is correct for this Conjur instance.

For an example of a Helm test as a reference, see:
https://github.com/cyberark/conjur-oss-helm-chart/tree/master/conjur-oss/templates/tests

Tests to be Performed

NOTE: This user story covers creating just the basic framework for the Namespace prep Helm chart.
More tests will be added subsequently via Issue #289, and Issue #290.

For the initial implementation of the Helm test for the Kubernetes Namespace prep Helm chart,
we'll include only a couple of simple tests (the Golden ConfigMap will be volume-mounted to the Helm test Pod/Job):

• curl -k <Conjur URL>
  This verifies that the Conjur server can be reached (i.e. logical ping) using the Conjur URL,
  regardless of whether the Conjur SSL certificate is accurate or not.
• Use the openssl utility to retrieve the Conjur SSL certificate using the configured Conjur URL,
  and verify that the retrieved SSL certificate matches the configured Conjur SSL certificate.
• OPTIONAL: Add more SSL certificate checking using openssl???

Required Components for Helm Test Framework

Helm Test Docker image

The Helm test will require a custom image that contains:

• curl
• openssl
  This image should be available when PR Adding the Heml test container to DockerHub #288 is merged.

Manifest for test Pod/Job

A Kubernetes manifest for a Pod or Job to run the test scripts is needed.
This can be ported from PR #229.

Manifest for test ConfigMap containing 'bats' test scripts

The tests scripts can be provided to the test Pod/Job as a ConfigMap.
We can port this ConfigMap largely from the ConfigMap created in PR #229,
with some minor modifications in ConfigMap keys / environment variable names.

Test Results Visiblity

The test results for failed test cases must be visible on the helm test command line.
When a failure occurs, it should be clear to the person running the test what the specific failure was.
It might be sufficient to dump the test Pod/Job logs when failure occurs.

Describe alternatives you have considered

A clear and concise description of any alternative solutions or features that may be related to this that
you have considered.

Additional context

Add any other context information about the feature request here.

DoD

-[ ] Helm test components created:
-[ ] Test Pod/Job manifest (Ported from PR #229 with minor change to field names)
-[ ] Optional: Test ConfigMap (Ported from PR #229 with minor changes to field names)
-[ ] Helm test happy path works
-[ ] Helm test fails for invalid Conjur config
-[ ] Failures are clearly described in helm test ... command output