-
Notifications
You must be signed in to change notification settings - Fork 15
OpenShift Conjur v5 Setup
Assumes that you are using a working OpenShift Origin cluster v3.9
These documents are a good place to get started, but we recommend prior experience with OpenShift.
- https://docs.openshift.com/container-platform/3.9/getting_started/install_openshift.html
- https://docs.openshift.com/container-platform/3.9/install_config/install/quick_install.html
If you used an unresolvable DNS name, make sure that you can access the server using that DNS name
echo "<ip-of-oc-master> <dns-name>" | sudo tee -a /etc/hosts
By default, OpenShift uses the DenyAll provider for the CLI/webconsole so we will replace the default identity provider with the Htpasswd provider.
Perform these steps on your OpenShift master:
Open /etc/origin/master/master-config.yaml
. You have to remove any old identityProviders
and replace it with our new one:
...
oauthConfig:
identityProviders:
- name: file_htpasswd_provider
challenge: true
login: true
mappingMethod: claim
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /etc/origin/openshift-htpasswd
...
As you can see we will use /etc/origin/openshift-htpasswd
as our user-to-password mapping file.
Restart all relevant services on master and then on all the nodes:
$ sudo systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
We will need 3 accounts set up:
- Cluster super administrator
- Namespace administrator
- Local developer
Perform these steps on your OpenShift master:
$ yum install httpd-tools #should already be available with the installer
$ htpasswd -B -c /etc/origin/openshift-htpasswd developer
Adding password for user developer
$ htpasswd -B /etc/origin/openshift-htpasswd admin
Adding password for user admin
$ htpasswd -B /etc/origin/openshift-htpasswd superadmin
Adding password for user superadmin
Log into the webconsole (https://<cluster-dns-name>:8443
) with all 3 usernames to ensure that all users can log in.
oc adm policy add-role-to-user registry-editor developer -n default
oc adm policy add-role-to-user basic-user developer -n default
oc adm policy add-role-to-user edit developer -n default
oc adm policy add-role-to-user admin admin -n default
oc adm policy add-role-to-user cluster-admin admin -n default
oc adm policy add-cluster-role-to-user cluster-admin superadmin
Now we should be able to log in remotely using the oc
tool:
$ oc login <hostname-of-master>
Username: superadmin
Password:
$ oc whoami
This step will bind the hostname of your cluster to the
$ oc create route passthrough docker-registry-public --service docker-registry --hostname <dns-name-of-master-node> -n default
route "docker-registry-public" created
If this is a completely new cluster, you will need to make a few changes to have the Docker Registry accessible over https. Since we won't be creating valid SSL certificates, we will need to make our local machine be accessible over an insecure connection from the local daemon.
Edit your version of daemon.json
for your OS. On an Linux and OSX machine this is in /etc/docker/daemon.json
(on OSX you can also do it in the UI under Preferences -> Daemon -> Basic -> Insecure Registries
). If your master cluster DNS name is foo.bar.local
, and you're adding this change directly to the file, this change in JSON is needed:
{
"insecure-registries": [
"foo.bar.local"
]
}
Note this should not include the protocol scheme.
You must restart your Docker daemon after this change using either the UI on OSX or on Linux restarting the service (sudo systemctl restart docker
).
You must have working oc login
to do this step!
To test that your registry is working properly, you can try logging in. In this example, our DNS name is foo.bar.local
.
$ docker login -u superadmin -p $(oc whoami -t) foo.bar.local
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded