As a Conjur operator, I want to be able to configure OS Conjur to support TLS, so that I can use authn-k8s, which requires mTLS.

GIVEN a Kubernetes environment
WHEN I deploy OS Conjur using the Helm chart
THEN Conjur is configured with nginx to support TLS

mTLS is needed to support authn-k8s authentication within the same cluster between the Conjur OSS (master) instance and clients (conjur-authn-k8s-client) sidecar or init container using service accounts.

Estimate: 2 weeks
Confidence: low

When attempted to deploy the helm chart, got an error about the deployment version.

C:\Users\username\Downloads>C:\Users\username\Downloads\helm-v3.0.2-windows-amd64\windows-amd64\helm.exe install --set dataKey="$(docker run --rm cyberark/conjur data-key generate )"  C:\Users\sthiyagara\Downloads\conjur-oss-1.3.7.tgz --generate-name

Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta2"

Need to investigate the correct API version to use for Deployment to support the needed K8s versions for our customers, and upgrade the manifests used by the helm chart.

Summary

If all of the following are true for an image tag Helm chart value:

• The tag value is set in a custom values.yaml file
• The tag is a numeric semantic version (i.e. no surrounding quotes are used)
• The tag is of the form <major_version>.<minor_version>
• The minor number is a multiple of 10

Then the trailing zeros of the minor version get truncated when the tag gets translated to
a Kubernetes manifest.

For example, a tag of 1.10 gets truncated to 1.1. This happens because the .10 in 1.10 is treated
as a decimal fraction.

This issue seems unavoidable if we allow tag values to be numeric.

It would be better to avoid this issue by only allowing string values (i.e. surrounding quotes should be required).

Steps to Reproduce

Steps to reproduce the behavior:

1. Copy values.yaml to custom_values.yaml
2. Modify any of the tag values in custom_values.yaml to 1.10
3. Run helm template ... or helm install --dry-run... with the -f custom_values.yaml option
4. Look at the rendered Kubernetes manifest, and you will see the 1.10 value trucated
   to 1.1.

Expected Results

Either:

• A numeric tag value with minor version that is a multiple of 10,
  e.g. 1.10 should not get truncated, OR....
• Numeric tag values should not be allowed.

Actual Results (including error logs, if applicable)

A tag value of 1.10 was truncated to 1.1 upon translation
to Kubernetes manifest.

Reproducible

• Always
• Sometimes
• Non-Reproducible

Version/Tag number

What version of the product are you running? Any version info that you can share is helpful.
For example, you might give the version from Docker logs, the Docker tag, a specific download URL,
the output of the /info route, etc.

Environment setup

Can you describe the environment in which this product is running? Is it running on a VM / in a container / in a cloud?
Which cloud provider? Which container orchestrator (including version)?
The more info you can share about your runtime environment, the better we may be able to reproduce the issue.

Additional Information

Add any other context about the problem here.

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

A clear and concise description of what the problem is. Ex. I would like to see [...] because [...].
Please include the intended use case and what the feature would improve on so that we can prioritize
the feature accordingly.

Describe the solution you would like

Current README.md and CONTRIBUTING.md only go so far as documenting how to spin up and maintain
a Conjur OSS cluster.

Additional guidance should be added for "Okay, I have a Conjur OSS cluster deployed, now what?".

This should include:

• How do I add a Conjur account (or better yet, automate this into the Helm chart)
• Examples of how to deploy applications that use authn-k8s
• How do I enable debug mode on Conjur for troubleshooting.

Describe alternatives you have considered

Additional context

We want to be in the charts here: https://github.com/helm/charts.

Figure out what needs to be done to submit this chart for verification.

Summary

If a Conjur OSS cluster is installed or upgraded using --set logLevel=debug,
then the documented method for retrieving the admin password (see
https://github.com/cyberark/conjur-oss-helm-chart/tree/master/conjur-oss#configuring-conjur-accounts)
fails since it captures not only the admin password, but also the preceding
debug log output.

Steps to Reproduce

Steps to reproduce the behavior:

1. Helm install using --set logLevel=debug --set account.name=myConjurAccount --set account.create=true
2. Follow the instructions for retrieving the Conjur admin password (see link above).
3. Observe that the output includes debug logs. The steps should ideally truncate this debug output.

Expected Results

Just the admin password should be displayed.

Actual Results (including error logs, if applicable)

Admin password get displayed but with preceding debug logs.

Reproducible

• Always
• Sometimes
• Non-Reproducible

Version/Tag number

Latest.

Environment setup

Any platform.

Additional Information

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

The Conjur OSS helm chart supports a "sliding" range of Kubernetes versions.
Jenkins-based automated CI is needed to continuously confirm proper Helm deployment
on a range of Kubernetes versions, including the latest release of Kubernetes.
This testing can make use of Kubernetes-in-Docker (KinD) to test against several
versions of Kubernetes clusters.

Describe the solution you would like

Automated testing that tests Conjur OSS Helm deployments on a range of Kubernetes versions,
including the most recent official release of Kubernetes.

Describe alternatives you have considered

Additional context

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

Currently there are no automated tests for Conjur OSS Helm charts based on GCP/GKE.

Describe the solution you would like

Automated tests exist for testing Conjur OSS Helm charts on GCP/GKE.

Describe alternatives you have considered

Additional context

When deployed into Google Cloud Platform via the Google Cloud Marketplace, the Conjur OSS helm chart will expose a mechanism to enable any authenticator(s) and run any additional services required for the authenticators to function properly.

When deploying from Google Cloud Marketplace:

1. From the Google Cloud Marketplace page https://console.cloud.google.com/marketplace/details/cyberark/conjur-open-source the user selects configure (Fig 1).
2. The user selects the project they want to launch Conjur into
3. Under Click to Deploy on GKE (Fig 2), the user
   1. Selects the cluster to launch into
   2. Selects the namespace to launch into
   3. Provides the app instance name to use
   4. Optionally provides the Postgres URL. If one is not supplied, a pod with Postgres is launched for the user.
   5. Optionally provides a list of authenticators to enable

Conjur will then be deployed into the cluster and namespace selected with the app instance name provided. It will use the supplied Postgres URL (or generated one for a launched Postgres instance) with the provided authenticators enabled. All additional services necessary (mTLS support for authn-k8s, etc.) to support the authenticators will be provided.

The assumption is that it is a single OSS instance communicating with an authn-k8s client (via sidecar or init container) deployed to a pod using service accounts. mTLS is assumed to be intra-cluster rather than the larger inter-cluster setup.

A scripted version of the client process is available at https://github.com/conjurdemos/kubernetes-conjur-demo and is expected to work with the above deployed Conjur OSS instance.

When deploying a client:

1. Create application namespace
2. Load Conjur policies into the Conjur OSS instance (see https://github.com/conjurdemos/kubernetes-conjur-demo/tree/master/policy for example policy templates)
3. Initialize the certificate authority (see https://github.com/conjurdemos/kubernetes-conjur-demo/blob/master/3_init_conjur_cert_authority.sh)
4. Store the Conjur certificate for application use (see https://github.com/conjurdemos/kubernetes-conjur-demo/blob/master/4_store_conjur_cert.sh)
5. Build and push client containers into Kubernetes registry.
6. Deploy test application to Kubernetes cluster (see https://github.com/conjurdemos/kubernetes-conjur-demo/blob/master/6_deploy_test_app.sh)
7. Verify client application can pull secrets

Right now, there is no way to enable different authenticators and even if enabled additional support is needed for the authenticators (such as mTLS for the kubernetes authenticator). This limits the capabilities and benefit of using Conjur. All authenticators should be usable when deployed via the helm chart.

Specific support is needed for kubernetes, it needs to support authn-k8s authentication within the same cluster between the Conjur OSS (master) instance and clients (conjur-authn-k8s-client) sidecar or init container using service accounts.

Fig 1

Fig 2

• Parent of #10 - Conjur Helm Chart does not expose CONJUR_AUTHENTICATORS
• Parent of #11 - Conjur Helm Chart supports configuring Conjur with TLS
• Parent of #13 - Update GCP with new helm chart
  • Parent of cyberark/conjur#820

Summary

Currently when we use html templates, they are not using html/template package but text/template and thus not loading the partials either.

Steps to Reproduce

• Run ./parse-changelogs -t docs-release

Expected Results

All output should follow html/template pattern where needed

Actual Results (including error logs, if applicable)

Output uses plain text/template transformation

Acceptance Criteria

• Ensure html templates use the proper template package
• Ensure html partials can work in integration test(s)
• Ensure that (if merged at that time) installation instructions for Conjur are moved to a partial

When using the Helm chart to deploy Conjur, there is no way to set the CONJUR_AUTHENTICATORS variable. This means we can't configure Conjur to for Authn-K8s.

Expected Behavior
We should be able to set CONJUR_AUTHENTICATORS so that users can use authn-k8s, or any other authenticator.

Estimate: 1 day
Confidence: high

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

• Update chart version in Chart.yaml to 2.0.1
• Update CHANGELOG.md accordingly
• Add minor updates to release instrux in CONTRIBUTING.md

Describe the solution you would like

The above is done.

Describe alternatives you have considered

Additional context

At current, we don't do any validation of the helm upgrade process in our pipeline.

In this issue, we'd like to add some automation to our pipeline to validate basic upgrade flows automatically, to reduce the XA load.

Before starting work on this card, please define the plan in a comment and seek feedback from the team.

Last XA plan (not everything necessarily needs to be tested in the pipeline, just sharing here for reference):

• Standard Conjur version upgrade post-release, deploys PG - Run default deploy flow in a recent K8s version using Helm v3 with Conjur v1.x and then run helm upgrade to Conjur v1.{x+1}. Verify:
  • Works as expected
  • Conjur certs are managed appropriately after upgrade
  • Data still available after upgrade via API
• Standard Conjur version upgrade post-release, remote PG - Run same flow as before, but with a remote PG instance
• Upgrade from old helm chart release to new helm chart release

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

Project management gave us some great suggestions re. the README.md for the
authn-k8s on KinD example. The suggestions were basically to make the
README.md more of a guided tour or a "Getting Started" guide.

The biggest part of this is to have the user jump into running the demo
right away, and then add background information about what the demo
scripts accomplished afterwards.

Describe the solution you would like

A clear and concise description of what the desired end result(s) would be.

Describe alternatives you have considered

The README.md should be reorganized so that the flow is, from a high level:

• High Level Overview: What this Demo Does
• Prerequisites
• Let's Run the demo
• Okay, What Did this Demo Just Do?
• Cleaning up

Additional context

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

Create a PoC for moving the PostGres container out of its own deployment into
the Conjur deployment.

Describe the solution you would like

• Postgres container runs in the Conjur pod, using a PVC that can be shared with postgres
  containers in other Conjur replicas.
• Conjur container can connect to the postgres container
• Conjur functionality works when replica count is more than 1

Describe alternatives you have considered

Additional context

Summary

When you install Docker on Linux without adding the current user to the Docker group (see here for more details) or run as root, the following line will fail due to the inner sub-shell inability to access the Docker socket:

helm install conjur-oss \ --set dataKey="(docker run --rm cyberark/conjur data-key generate)" cyberark/conjur-oss

Steps to Reproduce

Steps to reproduce the behavior:

1. Install Ubuntu
2. Install Docker without adding current user to Docker group
3. Try to follow installation instructions

Expected Results

Chart is installed

Actual Results (including error logs, if applicable)

Chart install fails

The CI pipeline is updated to run kubesec to verify resource configuration according to Kubernetes security best-practices / score the security of our helm chart implementation.

AC:

• Determine appropriate score threshold to use for this project
• Add kubesec to CI pipeline so that scores exceeding threshold cause build failure

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

The current Helm chart provides "home-grown" versions of YAML templates for
Conjur's Postgresql backend database. It would be much less maintenance for
us to use the open-sourced bitname/postgresql Helm chart that has been
tested and thoroughly vetted by a wide community.

Describe the solution you would like

There are two potential solutions that should be considered:

(1) Remove our current Postgresql YAML support and replace it
with documentation on how to either spin up a Postgresql
backend using the bitnami/postgresql Helm chart,
or use your own external database.
(2) Remove our current Postgresql YAML support and
add the bitnami/postgresql Helm chart as a subchart.

There is a Proof-of-Concept pull request that implements (2):
#83

Describe alternatives you have considered

The alternative is to leave things as is for Postgresql support
in our Helm chart, and continue to maintain this support.

Additional context

Add any other context information about the feature request here.

Currently the PostgreSQL instance which is deployed as part of Conjur OSS, is not persistent. This means that as soon as the database container stops, all the data in it is lost.

Expected Behavior
The Conjur Helm chart should expose a new parameter that can toggle the deployment of PostgreSQL as persistent. We can use this link as a reference.

GIVEN I have deployed Conjur OSS using the helm chart
AND I want to add or modify an environment variable in the Conjur container
THEN when I come to the helm chart README, there are clear instructions for modifying the Conjur environment variables
AND to modify the Conjur environment variables, I don't have to tear down my existing deployment and start a new one from scratch

AC:

• Update Conjur to v1.11.1
• Create a new project release

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

The Conjur OSS image supports a CONJUR_LOG_LEVEL environment variable,
but this environment variable is not set and is not configurable via the Helm
chart.

Describe the solution you would like

• conjur-oss/templates/deployment.yaml file includes a setting for the CONJUR_LOG_LEVEL
  environment variable, e.g.:

      - name: CONJUR_LOG_LEVEL
        value: {{ .Values.logLevel }}
  

• conjur-oss/values.yaml file provides a settable value for logLevel, e.g.:

  # Conjur log level. Set to 'debug' to enable detailed debug logs
  # in the Conjur container.
  logLevel: "info"
  

• conjur-oss/README.md includes documentation for setting this to enable debugging.

Describe alternatives you have considered

Additional context

Summary

The deployment instructions may be hard to follow without visuals.
Adding a few diagrams that show the target deployment architecture would be very beneficial.
For example -

1. pod layout showing which containers are used
2. networking diagram showing internal and external comm with ports

Note that some of these diagrams already exist elsewhere (ask @boazmichaely )

Expected Results

Users should be able to understand what they are building to start with, and verify that they have correctly built it at the end.

AC:

• Upgrade instructions give more details on the most common scenario where only conjur's image tag is bumped
• The README docs an example of installing the chart with an eternal DB connection URL

and upload the shasum file, like summon and summon-conjur do

• https://github.com/cyberark/summon-conjur/blob/master/package.sh#L30
• https://github.com/cyberark/summon-conjur/releases/latest

This way, our users can be more certain they're getting the correct files from us.

In trying to use this recently, I noticed a few small things that we could update to make it easier to use:

• Do you actually have to put “authn” in the authenticators list? I thought by default that authenticator was always on - using it this way here seems inconsistent with the rest of our documentation.

• A lot of the instructions for how to configure Conjur are displayed in the terminal when I install the helm chart, but the README doesn't tell me that's going to happen so it was really confusing until I ran the install command how I was going to configure Conjur.

• I know the helm chart installs Conjur, but (as described in the previous bullet) I don't know how Conjur gets configured (or that it needs to be configured). But in the README it says:

  If using the Kubernetes authenticator for Conjur, the account value (see Configuration) must match the initial Conjur account created. For example, given the following command

  At this point in the README, I have no idea how the initial Conjur account gets created. Do I set it? Is it a configuration variable? How do I know what to set this to when using the K8s authenticator? Even having run through this once, I think I'd have to run through it all again to figure out how to set the account to something other than default.

• There is a reference in the chart instructions (once you install) to set up your /etc/hosts, so I did that locally. Later I spun up a CLI container, though, and I had to set up /etc/hosts there too - that could be clearer in the instructions.

I hope these comments make sense - please feel free to get in touch if they don't. Basically a lot of the confusion stemmed from a lack of clarity around exactly what steps the helm chart covered vs what steps I would cover myself by following the instructions after install. It would be great to clarify this at some point.

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

Default versions of Conjur and Postgres should be upgraded to maintain parity with Conjur DAP:

• Upgrade default Conjur version from 1.5 to 1.10
• Upgrade default Postgres version from 1.12 to 10.14

Describe the solution you would like

See above.

Describe alternatives you have considered

Additional context

Kubernetes authn-k8s Authentication on Conjur-OSS

This epic tracks efforts to do an End-to-End UX test on deploying applications that use authn-k8s authentication on Kubernetes platforms using Conjur clusters that have been deployed via the Conjur OSS Helm charts. Included in this work is an audit of any documentation related to configuring Conjur for authn-k8s authentication and deploying applications that use various authentication clients, including Secretless broker, authn-k8s side car containers, and authn-k8s init containers.

Currently, there are two main methods of configuring application identity for authn-k8s:

• (Old style) Host-ID-based app identity, where the Kubernetes resource (e.g. ServiceAccount, Deployment,
  Namespace, etc) to be authenticated is included in the Conjur policy host ID using the suffix
  <namespace>.<k8s-resource-type>.<k8s-resource-name> in the authentication path.
• Annotation-based app identity (new style), where the host ID in the policy is an application name, and the
  specific Kubernetes resource to use for authentication is configured in the policy as an annotation
  on that applicationhost.
  included in the policy

Wherever practical, this epic will also include updates to automated integration tests to test various combinations of Kubernetes platforms, authentication workflows, and authentication clients.

Project Scope

In Scope

• Identify user pain points and documentation gaps while setting up applications using authn-k8s with Conjur-OSS clusters:
  • Platforms: GKE, OpenShift, KinD
  • Application identity schemes/workflows: host-ID based app identity, annotation-based
  • Authentication clients: Secretless Broker, authn-k8s sidecar, authn-k8s init container
• Deprecation of host-ID-based authentication: Update any documentation that currently uses host-ID
  based authentication to use annotation-based authentication.
• Enhance Conjur OSS Helm chart documentation to include examples of how to run applications that use authn-k8s
• Add troubleshooting documentation for debugging authn-k8s
• Wherever practical, add automated integration tests (Jenkins or Github actions based) for testing authn-k8s on Conjur-OSS
• After any changes are made to Conjur or demo scripts, test authn-k8s on Conjur DAP/appliance to check for regressions.

Out of Scope

Project Value Overview

• There have been many community issues filed involving using authn-k8s on Conjur-OSS. This is an obvious pain point.
• Setting up a "sandbox" to replicate issues involving authn-k8s is currently laborious and error-prone.

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

We can do some sanity validation on values using built-in JSON schema validator of Helm to improve UX.

Describe the solution you would like

• A reasonable JSON schema values.yaml validator file exists

Describe alternatives you have considered

N/A

Additional context

N/A

If the repo has a changelog that doesn't meet the standard, do try to change earlier entries to match the standard.
If the repo doesn't have a changelog use this as a starter:

# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).

## [Unreleased]

Acceptance criteria

• CHANGELOG.md exists and follows the KeepAChangeLog format. For reference consult https://github.com/cyberark/conjur/blob/master/CHANGELOG.md.
• Add parse-changelog validation step to Jenkinsfile. For reference consult https://github.com/cyberark/conjur/blob/master/Jenkinsfile#L27.

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

A couple of issues that arise when someone is trying to install a Conjur
cluster on platforms such as Kubernetes-in-Docker (KinD), MiniKube, or in
KataCoda are:

• persitentVolume.create is not set to false when there are no StorageClasses
  or PersistentVolumes available, leading to errors in starting the postgresql container.
• service.external.enabled is not set to false when there is no LoadBalancer
  support, leading to services being pending waiting for an external IP assignment
  that will never happen.

It would be nice to have very explicit configuration recommendations in the conjur-oss/README.md
for cases where there is no support for PersistentVolumes or LoadBalancers.

Describe the solution you would like

Two sections added to the Configuration section of the conjur-oss/README.md
suggesting that these settings be used for platforms such as KinD, MiniKube,
and KataCoda:

• --set persistentVolume.create=false
• --set service.external.enable=false

Describe alternatives you have considered

Additional context

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

Currently, when the KinD/Conjur demo scripts that are in
examples/kubernetes-in-docker complete, there are a couple of
residual Kubernetes resources that were used for test/validation
that don't add much value to the demo experience:

• test-app-with-host-outside-apps-branch-summon-init deployment:
  This is used in the kubernetes-conjur-demo scripts to test that authentication
  works with the Conjur host defined anywhere in the policy branch.
  (Other than associated policy, it is identical to the test-app-summon-init
  deployment).
• test-curl pod:
  This is used to test application services from within the Kubernetes
  cluster when external IPs are not available.

These deployment and pod can be deleted for the purposes of a demo.

Describe the solution you would like

At the end of the KinD demo, delete the
test-app-with-host-outside-apps-branch-summon-initdeployment
and the test-curl pod.

Describe alternatives you have considered

Additional context

AC:

• There is a github action to auto-package the helm chart on tags
• There is a github action to auto-publish github releases on tags, and the releases include the helm package

The Google Marketplace needs to be updated with the new helm chart.

From the onboarding document provided by google:

The process for updating your solution is very similar to initial onboarding. First, generate a new set of container images and push them to your staging repository. Then, contact your Cloud Launcher Partner Engineer to begin submission and review of a new version.

Once published, the new version will become the default for new customers. Existing customers will see new images pushed to existing tags. UI installations are always pinned to image digests and will not be automatically updated. We are recommending the same to customers performing CLI installation. You should provide instructions in your ​user guide​ for upgrading application images.

When the images are pushed, we should increment the tag and include that information in the request.

depends on #10 [x]
depends on #11 [ ]

This repository was running a Gitlab pipeline that is no longer functioning as originally designed, and there is no Jenkins pipeline for the project.

The Gitlab pipeline needs to be converted to a Jenkins pipeline so that automated tests can continue to run for this project.

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

Currently the Helm chart allows for the setting of a Conjur account environment variable for
the Conjur pod (defaulting to the account name "default"). However, the Helm chart
doesn't actually create the Conjur account after Conjur has been deployed, it merely
configures the account name as an environment variable for the Conjur pod. The
creation of a Conjur account is left up to the user as an independent step following Conjur
deployment, and it's also left up to the user to take care to use the same Conjur
account name for account creation as was used for Conjur cluster deployment.

So what happens if the user creates a Conjur account with a different name than was
used for deployment? Normally, this mismatch won't effect proper operation. However,
if applications are later deployed which use authn-k8s authentication, this mismatch
will cause Certificate Signing Requests (CSRs) from the authn-k8s client to the authn-k8s
plugin to fail authentication. This failure happens because CSR authentication uses the Conjur
account name that is configured as an environment variable, but an account with this name
doesn't exist.

This is a very tricky problem to troubleshoot.

To eliminate the potential for this mismatch, it would be better if the Conjur OSS helm chart
automatically created a Conjur account using the account name specified by chart value
following Conjur cluster deployment, so that the account environment variable and the
Conjur account that is created will always match.

Describe the solution you would like

Use a Helm post-install hook to deploy a Kubernetes job following Conjur deployment.
The task that this post-install job will do will be to use kubectl exec ... to execute
a Conjur account create command in the Conjur-OSS container in the Conjur-OSS pod.

Describe alternatives you have considered

An alternative is to document the hell out of this to make it clear that the Conjur account
that is created after deployment MUST match the account name using during Helm install...
but this leaves the window open for operator error.

Additional context

Summary

CI daily builds seem to have frequent failures from flaky tests.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to https://jenkins.conjur.net/job/cyberark--conjur-oss-helm-chart/job/master/
2. See unstable results

Expected Results

Green builds

Actual Results (including error logs, if applicable)

Sporadic failures

Reproducible

• Always
• Sometimes
• Non-Reproducible

Version/Tag number

Latest/master

Environment setup

Jenkins

Additional Information

N/A

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

The current Conjur OSS Helm chart templates include the creation of a Kubernetes ClusterRoleBinding
by default. The intent of the ClusterRoleBinding is to grant RBAC permissions for the Conjur's
Kubernetes authenticator across all namespaces.

A better approach is to not use a ClusterRoleBinding (which applies across
all namespaces), and instead rely upon users to create namespace-scoped
RoleBindings for those namespaces that have applications that require
authn-k8s authentication.

The creation of ClusterRoleBinding by default should be deprecated.
The conjur-oss/README.md and the conjur-oss/values.yaml files
should include deprecation warnings indicating that the rbac.create chart
value is being deprecated and will be replace by 2 separate setting
in the next major release:

• rbac.createClusterRole (defaulting to true)
• rbac.createClusterRoleBinding (defaulting to false)

Describe the solution you would like

A deprecation warning is added to the conjur-oss/README.md and
conjur-oss/values.yaml files as described above.

Describe alternatives you have considered

Additional context

This Chart currently is being tested manually. We want to test the Chart in a real k8s cluster.

These tests should also run in GitLab CI, with the gitlab-ci cluster in conjur-gke-dev.

Summary

If a Conjur cluster is created with the chart setting account.name explicitly being
set (i.e. not defaulted), then a couple of issues are seen:

1. The Conjur account gets created regardless of the value of account.create.
2. If this is followed up with a Helm upgrade, and account.name is not set
   to an empty string, then the Conjur server continually crashes with:

   Account 'myConjurAccount' already exists
   error: exit
   

Steps to Reproduce

Steps to reproduce the behavior:

1. Create a chart with --set account.name=foobar --set account.create=false
2. Observe that account gets created, even though account.create was set to false.
3. Do a Helm upgrade, e.g.:

   helm upgrade -n conjur-oss --reuse-values --recreate-pods conjur-oss ./conjur-oss
   

   and observe that the Conjur server container continually crashes.

Expected Results

• Account creation should depend upon value of account.create.
• Help upgrades should work when an account is already created
  even if --reuse-values is used (idempotency).

Actual Results (including error logs, if applicable)

See above.

Reproducible

• Always
• Sometimes
• Non-Reproducible

Version/Tag number

Latest

Environment setup

KinD, but it shouldn't matter.

Additional Information

Explicitly setting --set account.name="" might be a workaround for Helm upgrades.

More details TBA

We would like to perform XA using the draft updated documentation (link TBA) for Kubernetes authentication to run through the end-to-end experience of using Conjur OSS with Kubernetes-deployed applications.

We already support custom annotations as values for the conjur service and ingress. We should also do this for the deployment, since some operators like this use deployment annotations: https://github.com/banzaicloud/hpa-operator#autoscale-by-annotations.
This can default to {}.

Hi,

I have been trying to deploy the conjur-oss helm chart against a Openshift 4 cluster and have been facing permission issues. I suspect that the unprivileged/non-root restrictions imposed by Openshift's RBAC are the cause, but haven't found a straight forward way to work around yet.

Is there any recommended approach to run the conjur-oss helm chart in non-privileged containers?

Thanks in advance.

Jose

Nginx container:

2019/06/23 07:42:53 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)

Conjur-oss container:

Rails Error: Unable to access log file. Please ensure that /opt/conjur-server/log/production.log exists and is writable (ie, make it writable for user and group: chmod 0664 /opt/conjur-server/log/production.log). The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
authn-local requires directory "/run/authn-local" to exist and be a directory
authn-local will not be enabled
/usr/lib/ruby/2.5.0/fileutils.rb:232:in mkdir': Permission denied @ dir_s_mkdir - /opt/conjur-server/tmp/pids (Errno::EACCES) from /usr/lib/ruby/2.5.0/fileutils.rb:232:in fu_mkdir'
from /usr/lib/ruby/2.5.0/fileutils.rb:210:in block (2 levels) in mkdir_p' from /usr/lib/ruby/2.5.0/fileutils.rb:208:in reverse_each'

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

Currently most of the matrix config testing is done manually so this would be good to automate for quality, consistency, and stability.

Describe the solution you would like

AC:

• A helm install and upgrade matrix-style automated tests suite is run on pull requests
• A helm install and upgrade matrix-style automated tests suite is run on master builds

In some persistent storage types, such as NFS, the container might need a specific UID in order to be permitted to the shared volume. For more details, see the explanation here.

The PostgreSQL manifest yaml should specify under spec.template.spec.containers these lines:

{{ if .Values.postgres.securitycontext.create }}
securityContext:
  runAsUser: {{ .Values.postgres.securitycontext.uid }}
{{- end }}

For NFS, that UID would be 65534 which represents nfsnobody

In the values.yaml file, we should add the relevant configuration as well.

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

Describe the solution you would like

The Conjur OSS helm charts configure TLS encryption between the Conjur server pod and
the postgres pod, alleviating the need for configuring network policy.

Describe alternatives you have considered

Kubernetes network policy can be used.

Additional context

Summary

Today our helm chart doesn't support OCP because we require the conjur image to run as root and therefore to enable anyuid permission to the SA that will run the conjur deployment.

Expected Results

Install Conjur using helm chart on OCP 3.x 4.x

Additional Information

Our new container-dap project already have the fixes required to run without root.
We can take the fixes from the container-dap project and port them to the OSS project.