I’m trying to set up a local proof-of-concept of Conjur OSS within a Docker Desktop Kubernetes environment backed by WSL2 Ubuntu 18.04. It may be that this simply isn’t supported, but the docs claim that 1.5+ Kubernetes implementations are support.
Versions:
Docker Community edition
v2.3.4.0 edge
Kubernetes
v1.18.6
I’ve followed the guide and used the Conjur OSS Helm Chart with helm3.
I’m having trouble understanding what SSL certificates are required or how I should configure them for a local installation, but the doc says that “Conjur is running HTTPS on port 443 (9443 within the cluster) with a self-signed certificate”. The Conjur pods all start up (server, postgres) and the ingress service. I can hit the Conjur server fine on HTTPS localhost.
However, the final steps fail to connect using the client to the server to log in:
docker run --rm -it --entrypoint bash cyberark/conjur-cli:5
conjur init --force=true --url https://localhost --account=default
error: Unable to retrieve certificate from localhost :443
When I look at the ingress service, I see that the external port is not an IP address but “localhost”.
Furthermore, the external endpoint is created as http://localhost:443/
Does anyone have any clues or experiences that could help? The issue is compounded by both the configuration of Conjur and Kubernetes and I don’t see a way to resolve this.
It may be that this simply isn’t supported, but the docs claim that 1.5+ Kubernetes implementations are support.
In theory this should work fine but we don’t explicitly test in this setup - we usually use minikube or a real GKE cluster. Either way, I don’t think your setup is causing issues but I cannot speak with certanty.
docker run --rm -it --entrypoint bash cyberark/conjur-cli:5
I could be wrong but this may point to the fact that you are using kubernetes that opens a port on your host machine on port 443 which is not the same virtual IP as the ones that are tied to Docker container that you run the CLI in.
Try running the CLI container with docker run --rm -it --net host --entrypoint bash cyberark/conjur-cli:5 or you could also try a non-containerized CLI like the Python CLI that can run on your host directly (the CLI is alpha but has majority of the functionalities that a user may need).
I think you are right, either it’s not supported fully, I have a network mismatch using localhost, or the SSL certificate does not match in this scenario.
I tried with with docker run --rm -it --net host --entrypoint bash cyberark/conjur-cli:5 and got the same results, but will try with a non-containerized CLI. I suspect I may have to give up and use minikube or a real GKE cluster as I have no idea how to debug or solve this.
I definitely do not like the way that the Conjur OSS ingress service appears to expose http:/localhost:443 instead of https:/localhost:443, but have no basis for knowing if this is correct or not.
Adding to @sgnn7 answer, you won’t be able to use “localhost” in the below command: conjur init --force=true --url https://localhost --account=default
The CLI container will resolve localhost as being the CLI container.
By using the host network mode, the CLI container and the host will share the same network interface.
Hence localhost could be used, but what about other containers in bridge mode? Why would localhost:443 point to the Conjur container rather than the CLI container?
The Conjur OSS and CLI container could be placed in the same custom docker bridge network (not the default one that does not resolve container names anymore: https://docs.docker.com/network/bridge/). This way the Conjur CLI container can resolve the Conjur container’s name and you could use: conjur init --force=true --url https://conjur --account=default
either it’s not supported fully, I have a network mismatch using localhost, or the SSL certificate does not match in this scenario.
Correct. As far as I know though the Helm chart should work perfectly fine on GKE, another Kubernetes cluster, MacOS/*nix Docker setup, and many other platforms. In your case WSL2 + Docker Kubernetes + Local Docker container + networking is probably something that you will have problems on as Docker containers and Windows is (to be blunt) a barely functional platform as-is and we’ve had issues on other projects with this. I’m not saying that it can’t work (I would bet that it can) but it will probably not be the out-of-the-box experience.
I definitely do not like the way that the Conjur OSS ingress service appears to expose http:/localhost:443 instead of https:/localhost:443, but have no basis for knowing if this is correct or not.
I also cannot comment on the info from @JfcAtCyberArk if it works as I didn’t try them myself but his suggestions seem very reasonable. With that said, I would probably just move away from Windows as the Docker deployment host platform as that might be the fastest way to get yourself going with these until Microsoft improves their containerization support.
I really appreciate the time you (and @JfcAtCyberArk) have taken to answer my questions and provide suggestions/comments.
In the end I moved away from Windows/Docker and implemented on GKE, which worked eventually - So I’m up and running. The GCP ‘Conjur Open Source’ failed using both the marketplace installer and as described here but I’m not sure they’re mainatined.
Hey Lee,
That’s great news - glad you got it working!
PS: As to our GCP application, the Kubernetes API changed not too long ago that broke it and we have all the fixes already needed done but we’re still navigating through all the steps to get the app re-published and approved again .
.