A test setup exists for testing simplified authn client config

[diverdane]

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

Related User Stories

• As a CyberArk developer of the simplified authentication client configuration (documented in Issue Design: there is a design document for Simplified Kubernetes Client Configuration #2045), I need a test setup for testing the proposed workflow using the new Helm templates, so that the Helm chart designs and the workflow can be verified.
• As a Conjur community member, I need to have a set up to use for a Quick Start guide that walks people through the process of deploying Conjur-enabled applications on Kubernetes using the workflow proposed in Issue Design: there is a design document for Simplified Kubernetes Client Configuration #2045.
• As a CyberArk developer of Secrets Provider write-to-file, I need a test setup that will provide quick iterations for testing code changes.

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

• The cyberark/kubernetes-conjur-deploy scripts are used extensively by developers and by folks in the field. Adding new functionality based on the new Helm charts would risk disruptions if changes are introduced that inadvertently break existing support.
• The conjurdemos/kubernetes-conjur-demo scripts are already overwhelming in terms of all the combinations and permutations of platforms supported (kubernetes vs OpenShift), Conjur OSS vs. Conjur enterprise, and Conjur authenticator sidecars/init containers (authn-k8s, secretless broker, etc.) Adding yet another combination to the mix would add to the "Swiss Army Knife from Hell" aspect of this project.
• Iterations will be much quicker if ONLY ONE Conjur authenticator type is being tested rather then including all types of authenticator sidecar/init containers.

Describe the solution you would like

Proposed Support

Assumptions

The test setup should assume that the following have already been deployed:

• Kubernetes cluster (could be KinD or OpenShift)
• Conjur Cluster (could be Conjur OSS or Conjur Enterprise/DAP)

Workflow to be Supported

The test setup should support the following workflow:

• Kubernetes cluster prep using new Cluster Prep helm chart
• Deployment of a Conjur CLI pod if one is not present
• Loading of authenticator Conjur policy using Conjur CLI pod
• Application namespace prep using new Application Namespace prep Helm chart
• Loading of application Conjur policy using Conjur CLI pod
• Deployment of a Pod that contains the Secrets Provider Init container and an application (e.g. debian or Pet Store)

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:

• Test with a SINGLE authenticator + application combination (initially Secrets Provider only)
• Use the new Helm charts (cluster prep and namespace prep) instead of corresponding bash scripts
• Modify pod manifests to use the simplified Conjur configuration (i.e. Conjur Connection ConfigMaps) rather than hard-coded environment variables
• OPTIONAL: Create a new Helm chart to deploy the application, rather than using 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!!!!

1. Copy / Port scripts that do Conjur policy rendering and loading in conjurdemos/kubernetes-conjur-demo
2. OPTIONAL: Split Conjur authenticator-specific policy from application specific policy (generation and loading)
3. Create new scripts that call helm install ... to instantiate the new Helm charts (cluster prep and namespace prep)
4. EITHER: Create new sample application deployment Helm chart OR port scripts in conjurdemos/kubernetes-conjur-demo repo that do kube manifest rendering and kubectl deploy of applications + authenticator.
5. Modify application manifests to use new Conjur connection ConfigMaps.

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.

[diverdane]

As described in Issue #2063, this issue will be broken out into 3 separate, smaller issues.
The details from Issue #2063 are copied here:

Prerequisites / Assumptions / Separate Work

Required Helm charts

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:

• Cluster prep Helm chart (There is a helm chart to prepare a cluster for Conjur Kubernetes Authentication conjur-authn-k8s-client#227)
• Namespace prep Helm chart (There is a helm chart to prepare a namespace in a cluster for Conjur Kubernetes authenticationi conjur-authn-k8s-client#236)

Conjur deployments are assumed available

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:

• Conjur OSS CI (There are end-to-end tests for Kubernetes sidecars with Conjur OSS in Kubernetes conjur-authn-k8s-client#242)
• Conjur Enterprise with follower inside Kubernetes (There are end-to-end tests for Kubernetes sidecars with Conjur Enterprise and follower(s) in Kubernetes conjur-authn-k8s-client#243)
• Conjur Enterprise with follower outside Kubernetes (There are end-to-end tests for Kubernetes sidecars with Conjur Enterprise and follower outside Kubernetes conjur-authn-k8s-client#244)
• Conjur Enterprise with follower outside OpenShift (There are end-to-end tests for Kubernetes sidecars with Conjur Enterprise and follower outside OpenShift conjur-authn-k8s-client#245)

Required Workflow

The test setup should support the following workflow:

• Kubernetes cluster prep using new Cluster Prep helm chart
• Deployment of a Conjur CLI pod if one is not present
• Loading of authenticator Conjur policy using Conjur CLI pod
• Application namespace prep using new Application Namespace prep Helm chart
• Loading of application Conjur policy using Conjur CLI pod
• Deployment of a Pod that contains one of the following authenticator containers and an application (e.g. debian or Pet Store)
  • Secrets Provider init container
  • Secrets Provider standalone app container
  • Secretless Broker
  • authn-k8s sidecar
• Validation that the application can access Conjur secrets

Issues Which will Accomplish the Creation of an E2E framework

=========================================================

• There is a helm chart for deploying a sample app with a Conjur sidecar conjur-authn-k8s-client#238:
  There is a helm chart for deploying a sample app with a Conjur sidecar

=========================================================

• There are reusable scripts for development environments and automated testing conjur-authn-k8s-client#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 There are reusable scripts for development environments and automated testing conjur-authn-k8s-client#239 can be developed as follows:

  • Start with a clone/fork of the conjurdemos/kubernetes-conjur-demo script repository
  • Modify the 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).
  • Delete the 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.
  • Modify the 4_app_create_namespace.sh to:
    • Eliminate the creation of the RoleBinding
    • Add invocation of helm install ... for cluster prep helm chart (could be a separate bash script)
    • Add invocation of helm install ... for Namespace prep helm chart (could be a separate bash script)
  • Delete the 5_app_store_conjur_cert.sh script and remove its invocation from start
  • Modify the 7_app_deploy.sh to use new sample Application deploy Helm chart

=========================================================

• Deployment scripts include support for Secrets Provider init and standalone app containers conjur-authn-k8s-client#247:
  Add support for Secrets Provider init/app container to reusable scripts
  • Modify the policy templates in the policy subdirectory to include application policies for
    Secrets Provider init container and Secrets Provider standalone "app" container.
  • Modify the 7_app_deploy.sh to include Helm install of applications that use
    Secrets Provider init container and Secrets Provider standalone "app" container.
  • Modify 8_app_verify_authentication to add verification that applications using
    Secrets Provider can access Conjur secrets.

=========================================================

• Conjur OSS install on OpenShift conjur-authn-k8s-client#248:
  Deployment scripts include support for OpenShift
  • In the policy subdirectory, add Conjur policy host definitions for sample applications that will
    be run on OpenShift.
  • Using the conjurdemos/kubernetes-conjur-demo scripts as a reference, make sure that the
    calls to the oc CLI that appear in the kubernetes-conjur-demo scripts are also
    included in the scripts created by Issue Update Installation docs #239:
  • Modify the 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.

=========================================================