Open diverdane opened 3 years ago
As described in Issue #2063, this issue will be broken out into 3 separate, smaller issues. The details from Issue #2063 are copied here:
The E2E scripts that are being developed as described in Issue #2062 depend upon the availability of two Helm charts that are being developed in separate issues:
For the E2E workflow described below, it's assumed that a Conjur instance has been deployed and is available at the time that the E2E workflow scripts / Helm deployments are invoked. The "front end" work of deploying Conjur instances will be developed in these CI-centric issues:
The test setup should support the following workflow:
=========================================================
=========================================================
https://github.com/cyberark/conjur-authn-k8s-client/issues/239: There are reusable scripts for development environments and automated testing
NOTE: These scripts skip the addition of support for Secrets Provider init/app containers. This support will be added incrementally and separately (see Issue #xxxxxx)
This issue involves basically making a copy or fork of conjurdemos/kubernetes-conjur-demo scripts and modifying these scripts to use Helm chart installs (for cluster prep, Namespace prep, and application deploy), rather than using bash/sed/kubectl to do deployments.
The scripts for Issue https://github.com/cyberark/conjur-authn-k8s-client/issues/239 can be developed as follows:
set_env_vars.sh
script to define & set environment variables that will be used
as --set <key>=<value>
command line settings for all chart values in each Helm chart
(cluster prep, Namespace prep, and application deploy). (See the values.yaml
files in
each Helm chart to see what values are needed).0_prep_check_dependencies.sh
file, and remove its invocation from the start
script. The Helm charts should now provide the required checking for required settings.4_app_create_namespace.sh
to:
helm install ...
for cluster prep helm chart (could be a separate bash script)helm install ...
for Namespace prep helm chart (could be a separate bash script)5_app_store_conjur_cert.sh
script and remove its invocation from start
7_app_deploy.sh
to use new sample Application deploy Helm chart=========================================================
policy
subdirectory to include application policies for
Secrets Provider init container and Secrets Provider standalone "app" container.7_app_deploy.sh
to include Helm install of applications that use
Secrets Provider init container and Secrets Provider standalone "app" container.8_app_verify_authentication
to add verification that applications using
Secrets Provider can access Conjur secrets.=========================================================
oc
CLI that appear in the kubernetes-conjur-demo scripts are also
included in the scripts created by Issue #239:7_app_deploy.sh
to include deployment of applications using the Secrets Provider
init and app container authenticators (i.e. by passing the necessary chart values to the
application deployment Helm chart.=========================================================
Is your feature request related to a problem? Please describe.
Related User Stories
Background
Issue #2045 proposes a new workflow that uses a simplified way of configuring Conjur authenticator sidecar/init containers (initially includes just the Secrets Provider, but will ultimately include authn-k8s and Secretless Broker containers). We need a development test environment to test the new Helm charts (Kubernetes Cluster Prep Helm chart and Application Namespace prep Helm chart) as they are being developed, along with testing the proposed workflow with a Secrets Provider init container.
Once such a setup has been created, the test setup can potentially be used by community members in support of a Conjur Kubernetes authenticator Quick-Start guide that walks people through the newly proposed workflow for deploying Conjur-enabled applications on Kubernetes.
Problems with extending existing Secrets Provider test setup for testing new workflow
The existing Secrets Provider testing focuses primarily on testing Secrets Provider functionality. As such, it would be involved. and also disruptive to engineers working on that project to add test flows that make use of the Conjur Connection ConfigMaps that are proposed in Issue #2045.
Problems with extending existing kubernetes-conjur-deploy and kubernetes-conjur-demo scripts for testing the new workflow
Describe the solution you would like
Proposed Support
Assumptions
The test setup should assume that the following have already been deployed:
Workflow to be Supported
The test setup should support the following workflow:
Leveraging the Existing Kubernetes-Conjur-Demo scripts as a starting point
Much of what is required for this issue is available in the form of Bash scripts and manifest templates in the conjurdemos/kubernetes-conjur-demo. This project can serve as a starting point for a new project. The changes that would need to be done to the existing kubernetes-conjur-demo project:
bash
+sed
to modify manifest templates and bash scripts to kubectl create objects. This would provide a much better presentation for a Quick-Start guide.Work Items: SPLIT OUT INTO SEPARATE ISSUES AS REQUIRED!!!!
helm install ...
to instantiate the new Helm charts (cluster prep and namespace prep)Describe alternatives you have considered
Alternative: Modify conjurdemos/kubernetes-conjur-demo scripts. Disadvantages are listed above.
Additional context
Add any other context information about the feature request here.