There is an initial namespace prep Helm chart

[diverdane]

Overview

The proposed simple Kubernetes authenticator client configuration workflow requires the implementation of a Helm chart to create objects in an application Namespace as required for any Conjur Kubernetes authenticators that will reside in that application Namespace.

Desired Implementation

Objects to be Created

When helm install ... is invoked on this Helm chart, there should be two Kubernetes objects created in the application Namespace:

• Conjur Connect ConfigMap
• Authenticator RoleBinding

Required Chart values

This chart will require the following values to be set by the user:

• authnK8s.namespace
• authnK8s.goldenConfigMap

Introspection using Helm lookup function

This Helm chart needs to create objects using content from a "golden" ConfigMap that contains reference Conjur connection information. This golden ConfigMap will reside in a separate (centralized) Conjur or authn-k8s Namespace.

Values that will need to be introspected from this golden ConfigMap:

• authnK8sAuthenticatorID
• authnK8sClusterRole
• authnK8sServiceAccount
• conjurAccount
• conjurApplianceUrl
• conjurSslCertificateBase64 (lookup must use base64 encoded value since it doesn't work with introspecting multiple line values)

Sample Conjur Connect ConfigMap Manifest

When helm install ... is invoked using this Helm chart, Helm should render a manifest for a ConfigMap that looks similar to the following:

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: conjur-connect-configmap 
  labels: 
    app.kubernetes.io/name: <authnK8s.Namespace from chart values>-authn-k8s 
    app.kubernetes.io/component: conjur-conn-configmap 
    app.kubernetes.io/instance: <application namespace>-authn-k8s 
    app.kubernetes.io/part-of: app-namespace-config 
    app.kubernetes.io/managed-by: helm 
    helm.sh/chart: authn-k8s-namespace-prep-1.0.0   <--- Note: This chart's name and version
data: 
  CONJUR_ACCOUNT: myConjurAccount  
  CONJUR_APPLIANCE_URL: https://conjur.conjur-ns.svc.cluster.local 
  CONJUR_AUTHN_URL: https://conjur.conjur-ns.svc.cluster.local/authn-k8s/my-authenticator-id 
  CONJUR_SSL_CERTIFICATE: <unencoded Conjur SSL certificate>

Sample RoleBinding Manifest

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: <authenticator namespace>-conjur-authenticator-role-binding
  labels: 
    app.kubernetes.io/name: <authnK8s.Namespace from chart values>-authn-k8s
    app.kubernetes.io/component: rolebinding
    app.kubernetes.io/instance: <application namespace>-authn-k8s 
    app.kubernetes.io/part-of: app-namespace-config 
    app.kubernetes.io/managed-by: helm
    helm.sh/chart: authn-k8s-namespace-prep-1.0.0   <--- Note: This chart's name and version
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: <authnK8sClusterRole from golden ConfigMap>
subjects:
- kind: ServiceAccount
  name: <authnK8sServiceAccount from golden ConfigMap>
  namespace: <authnK8s.Namespace from chart values>

Helm chart Files to be created

This Helm chart requires the creation of the following files in the chart subdirectory:

• values.yaml file
• templates/conjur_connect_configmap.yaml templated manifest
• templates/rolebinding.yaml templated manifest
• README.md explaining basic usage, upgrade examples, and a table of configurable values
• templates/NOTES.txt simply announcing completion, maybe listing objects that have been deployed

Out of Scope:

• values.schema.json (covered in Issue #250)
• Unit test based on unittest framework (https://github.com/lrills/helm-unittest) (covered in Issue #251)
• Helm release validation using helm test

values.yaml requirements

Required Values:

The following values are required, and must be set in a values.yaml file or with a --set <key>=<value> command line setting (written in dotted path syntax):

• authnK8s.goldenConfigMap
• authnK8s.namespace

Fields with defaults:

• conjurConfigMap.name (defaults to -configmap)
• authnRoleBinding.name (defaults to -rolebinding)

Other control knobs:

For future-proofing, we should have knobs to individually enable/disable creation of ConfigMap and RoleBinding (just in case these objects are already being created somewhere else):

• conjurConfigMap.create (defaults to "true")
• authnRoleBinding.create (defaults to "true")

Template manifests requirements

The template manifests must enforce that required values have been explicitly defined.

README.md requirements

The README.md must include:

• Overview of the intended use of the chart.
• Step-by-step instructions on how to use the Helm chart, including:
  • Required values
  • Examples on how Helm upgrade can be used to modify values used by a chart
  • Table of configurable values
  • Explanation of why helm template ... and helm install --dry-run won't work as expected because lookup function won't perform retrospection for these commands.

NOTES.txt requirements

NOTES.txt should announce completion, maybe listing objects that have been deployed

Environments on Which to Test

For initial implementation, it should be sufficient to test this Helm chart on:

• Conjur OSS
• Either Kubernetes cluster (can be KinD or GKE) or OpenShift, pick one

Describe alternatives you have considered

Additional context

DoD:

• [x] Required chart files have been created
• [x] Helm chart tested on setups described in "Environments on Which to Test" above
• [x] Helm install creates Conjur Connect ConfigMap and RoleBinding using default enable flags
• [x] Labels are created correctly on both ConfigMap and RoleBinding
• [x] Disabling of ConfigMap creation works for helm install
• [x] Disabling of RoleBinding creation works for helm install
• [x] Helm upgrade works as expected
• [x] Requirements listed above are all met

[izgeri]

We rolled 1 pt into the next sprint