ConjurOps is currently running v4. In order to get early feedback on v5 changes, take advantage of new features and have a robust pipeline, ConjurOps needs to be updated to v5. The approach is defined into different phases in order to allow regular checkpoints on continuing work and making adjustments based on discoveries.

Goals of the upgrade

• Find bugs and issues sooner in the process​
• Reduce time to perform XA​
• Improve Conjur design​
• Expose deficiencies in documentation​
• Improve overall UX of Conjur​
• Improve automated tests​
• Define pattern for v4 -> v5 upgrade

Final target

The approach to use has changed and needs to be detailed. The existing phases and issues need to be updated and changed to match the new approach to use.

• v5 cluster that uses HA/failover + follower and 3rd party certs automatically (and regularly) deployed and upgraded using the latest built version​
• Automated validation of deployed v5 cluster​
• v5 cluster regularly used for secret and variable retrieval

Phase 1

The purpose of phase 1 is to get an initial v5 cluster up and running and available for use.

• Parent of #724 - A ConjurOps v5 cluster is available and can be easily redeployed

Phase 2

The purpose of phase 2 is to automate deployment and upgrade of a v5 cluster.

• Parent of #739 - V5 Cluster can be automatically created and destroyed
• Parent of #743 - v5 cluster is monitored for health
• Parent of #708 - V5 cluster can be automatically deployed and upgrade

Phase 3

The purpose of phase 3 is to fully integrate all changes and automation into the CI/CD workflow for Conjur.

• Parent of #709 - Automation is integrated into the build process to automatically deploy new versions

Phase 4

The purpose of phase 4 is to get to a point where everything except for the data stored in Conjur can be moved from v4 to v5.

• Parent of #675 - v4 policy can be automatically converted to v5 policy

Phase 5

The purpose of phase 5 is to get to a point where all structure and data can be migrated from a v4 cluster into a v5 cluster and the process is smooth and reliable.

• Parent of #676 - Full data can be exported from a v4 instance and imported into a v5 instance
• Parent of #677 - Upgrade process from v4 to v5 is smooth, reliable and predictable

Missing Features

In addition to the upgrade itself from v4 to v5, some features of Conjur v4 are used that are not present in v5 and need to be added to allow us to use the upgraded cluster. Jenkins currently uses a pam_ldap config to provide UI login to Jenkins that is backed by Conjur (which acts as an LDAP server). Additionally, it uses SSH keys stored in Conjur to provide ssh and sudo access to Jenkins master and executor servers. At a minimum, SSH support is needed. At this time, there are workarounds that can be used, so that should be done until the necessary epic is prioritized and completed

• Parent of #248 - Conjur supports SSH management