Securing Secrets in the CI/CD Lifecycle with Conjur

Hi everyone,

I am currently doing an internship on Secret Management within the CI/CD Lifecycle, and I am utilizing CyberArk Conjur as part of my project. I wanted to share my progress and seek some advice from the community.

As you can see in the screenshot above, I have set up my environment with the following components:

  • User’s desktop
  • Gitlab server of my organization
  • Ubuntu server running Jenkins (in Docker) and Kubernetes (minikube) with my frontend, backend, and database.

Currently, all the credentials in my CI/CD pipeline are hard-coded.

I have access to Conjur Enterprise and my organization already has a PAM (Privileged Access Management) solution from CyberArk. My ultimate goal is to utilize Vaults in CyberArk for secure credential storage with automated rotation.

One question I have is whether I need additional servers for my test environment, or if the current setup is sufficient?

Any advice or best practices for using CyberArk Conjur in a CI/CD pipeline would be greatly appreciated!

Thanks advance,
Vince

After completing the free online course, I came up with this:

Is it possible to add the “follower” to my existing server? Or should I create add a separate it?
And do you need 2 standby server (for a test environment)?

Thanks in advance!
Vince

  1. The follower just needs Docker for hosting, so there’s no reason why it cannot be included in “Ubuntu Server”. However, depending on the load you expect or if you’re trying to solve for high-availability, it may not be needed at all. If you’re not expecting a high-demand of secret retrievals or need local resiliency of the service, you can just go directly to the Leader node instead.
  2. If you’ll be having the cluster auto-failover, an odd number of Leader/Standbys is required for a quorum to be realized for the raft consensus. If you are not implementing auto-failover, you can survive with a single standby handling synchronous replication.

Standard production-level deployment is:

  • 1 Leader
  • Even Number of Standbys w/ 1 in the same data center as the Leader synchronously replicating
  • Followers deployed into each datacenter/cloud region in pairs for high-availability
    • Follower pairs behind a load balancer for HA
    • Followers communicate to Leader/Standbys through a load balancer with health check applied to Leader node to support auto-failover triggering

Hi Joe,

Thank you for getting back to me. I have decided not to use followers, but will use two standby nodes.

I also have a question regarding the use of a load balancer when not using followers. Is it mandatory to have a load balancer in this setup? If so, can I set it up using HAproxy? Are there any specific rules or additional information available on how to properly configure it?

Thanks in advance!
Vince