You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CI automation is required to perform E2E testing of the deployment of Kubernetes authenticator sidecars
using Conjur Enterprise with followers in the same Kubernetes cluster as the authenticator sidecars.
This task will use the E2E scripting that is created in Issue #239 to do the "backend" work of deploying the authenticators and a sample sidecar application.
However, scripts will need to be added to add a "front-end" installation of Conjur Enterprise with followers in the Kubernetes cluster (to be done before calling the scripts developed for Issue #239). This can probably be based on dap-intro scripts to deploy a Conjur enterprise instance in Jenkins with followers in the Kubernetes cluster.
TBD
Which clusters does this need to run in?
The Conjur followers, authenticator containers, and applications need to run in a "Kubernetes cluster".
This can probably be either:
Jenkins+GKE, or...
Github Actions + KinD
although this may depend upon easily those types of clusters integrate
with the dap-intro scripts specifically considering how followers can be created in that cluster.
Which sidecar flows will run?
Since E2E flows for all of the authenticator sidecar/init container types is already covered in
Issue There are end-to-end tests for Kubernetes sidecars with Conjur OSS in Kubernetes #242 (E2E using Conjur OSS), it may be sufficient to test one type of authenticator
sidecar/init container here. (The assumption here is that if one authenticator sidecar/init
container type can authenticate with a given configuration, the others "should" work in
that they should be fairly agnostic of the endpoints they're using for authentication???)
Is there prep work that needs to happen in dap-intro to get this working?
e.g. install/configure k8s follower from dap-intro? Make leader cluster available on a high port
in dap-intro so that it will be accessible from the cluster?)
Overview
CI automation is required to perform E2E testing of the deployment of Kubernetes authenticator sidecars
using Conjur Enterprise with followers in the same Kubernetes cluster as the authenticator sidecars.
This task will use the E2E scripting that is created in Issue #239 to do the "backend" work of deploying the authenticators and a sample sidecar application.
However, scripts will need to be added to add a "front-end" installation of Conjur Enterprise with followers in the Kubernetes cluster (to be done before calling the scripts developed for Issue #239). This can probably be based on dap-intro scripts to deploy a Conjur enterprise instance in Jenkins with followers in the Kubernetes cluster.
TBD
The Conjur followers, authenticator containers, and applications need to run in a "Kubernetes cluster".
This can probably be either:
although this may depend upon easily those types of clusters integrate
with the dap-intro scripts specifically considering how followers can be created in that cluster.
Since E2E flows for all of the authenticator sidecar/init container types is already covered in
Issue There are end-to-end tests for Kubernetes sidecars with Conjur OSS in Kubernetes #242 (E2E using Conjur OSS), it may be sufficient to test one type of authenticator
sidecar/init container here. (The assumption here is that if one authenticator sidecar/init
container type can authenticate with a given configuration, the others "should" work in
that they should be fairly agnostic of the endpoints they're using for authentication???)
e.g. install/configure k8s follower from dap-intro? Make leader cluster available on a high port
in dap-intro so that it will be accessible from the cluster?)
Dependencies
DoD
The text was updated successfully, but these errors were encountered: