How To Securely Set Up Shipyard 2.0.10 with TLS on CoreOS.

Khaled Naser

Khaled Naser

Shipyard is a management tool for Docker servers. Docker is a cutting-edge piece of software used for containerization. Shipyard allows you to see which containers each of your servers are running, in order to start or stop existing containers or create new ones.
Once you’ve set up Shipyard on your server you can access it using a graphic interface, a command-line interface, or an API.Shipyard lacks some of the advanced features of other Docker orchestration tools, but it’s very simple to set up, free to use, and you can manage and host it yourself. It also lets you manage resource allocation to specific containers and manage containers across multiple Docker hosts. However, it’s important to ensure that your Docker server and Shipyard system are secure, especially if they are being used in production.

In this article, we are going to show you Shipyard 2.0.10 installation setup on a single CoreOS server and securing Docker with a TLS certificate to ensure that only authorized clients may connect to it. TLS Stands for Transport Layer Security which is used to encrypt data as it is transported from the client to the server and back again. Here, we’ll use it to encrypt our connection to the Docker host, and Docker’s connection to Shipyard.


In order to setup shipyard 2.0.10 with TLS on CoreOS, we need to make sure that following prerequisites are complete.

First of all setup one CoreOS Droplet with at least 1 GB or more recommended RAM and choose the latest stable version of CoreOS. Login to your server using SSH-key as all CoreOS servers require an SSH key, then setup a fully qualified domain name (FQDN) or subdomain for your Docker host.

Now lets start with setting up Docker to use certificates for authentication.

1) Creating the Server Certificate:

CoreOS comes with OpenSSL, a utility that can be used to generate and sign certificates. Let’s create a Certificate Authority that we can use to sign server and client certificates.

First, create and move to a directory called ‘dockertls’, so it’s easy to remember where the files are.

$ mkdir ~/dockertls
$ cd  ~/dockertls

Then create an RSA private key using below command which will prompt you to create a passphrase for your key.

$ openssl genrsa -aes256 -out private-key.pem 4096

Here in this command genrsa will generate a private RSA private key. -out private-key.pem specifies the name of the file we want to generate, which is ‘private-key.pem’ and the last bit, 4096, is the length of the key in bits. It’s recommended to keep this at a high number like 4096.

Next, generate a new certificate and sign it with the private key we just created. You’ll need to enter the same passphrase you chose when creating the key.

$ openssl req -new -x509 -sha512 -days 365 -key private-key.pem -out myca.pem

Here OpenSSL will also ask for some required information, like the FQDN of your server and the county your organization is based out of. Let’s try to answer these questions as accurately as possible. This is the last step in creating our self-signed Certificate Authority, or CA as shown below.

creating certificate

After creating CA, we will create some server certificates for use with the Docker daemon. The following two commands generate a signing request but sure to replace test.com with the domain or subdomain of your own you using for Docker.

$ openssl genrsa -out docker-1-key.pem 4096
$ openssl req -subj "/CN=example.com" -sha512 -new -key docker-1-key.pem -out docker.csr

Finally, sign with the CA’s private key. You’ll need to enter the key passphrase again.

$ openssl x509 -req -days 365 -sha256 -in docker.csr -CA myca.pem -CAkey private-key.pem -CAcreateserial -out final-server-cert.pem

This will create a file in the current directory called final-server-cert.pem, which is the server certificate that will be used on the Docker host.

server cert setup

2) Creating the Client Certificate:

After creating server certificate, we need to create a client certificate. This will be used whenever we try to connect to the Docker host. It will verify that the client connection has actually been verified and signed by our personal CA. Therefore, only authorized clients will be allowed to connect and send commands to Docker.

First, create another signing request for the client using below commands.

$ openssl genrsa -out client-key.pem 4096
$ openssl req -subj '/CN=client' -new -key client-key.pem -out docker-client.csr

We need to create a config file which specifies that the resulting certificate can actually be used for client authentication.

$ echo extendedKeyUsage = clientAuth > client.cnf

The will creates a file called 'client.cnf' with the content extendedKeyUsage = clientAuth without needing to use a text editor.

Next, sign the client with the CA key.

$ openssl x509 -req -days 365 -sha512 -in docker-client.csr -CA myca.pem -CAkey private-key.pem -CAcreateserial -out client.pem -extfile client.cnf
Signature ok
Getting CA Private Key
Enter pass phrase for private-key.pem:

Now we have a CA, a server certificate, and a client certificate setup let’s move to the next step.

3) Configuring Docker and CoreOS:

In this step, we’ll configure the Docker daemon to use our certificates by modifying the startup options for Docker. CoreOS uses systemd command to manage services.

Let’s start by editing the Docker unit file. There’s an option for the systemctl command that will help us by duplicating the actual unit file instead of modifying the original directly. Open the Docker unit file for editing using systemctl as shown.

$ sudo systemctl edit --full docker

This will open the file for editing using vim, find the line that begins with ExecStart=/usr/lib/coreos/dockerd. Append this line with below config after –host=fd:// of that line as shown.

ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// --tlsverify --tlscacert=/home/core/dockertls/myca.pem --tlscert=/home/core/dockertls/final-server-cert.pem --tlskey=/home/core/dockertls/docker-1-key.pem -H=  $DOCKER_OPTS $DOCKER_CGROUPS $DOCKER_OPT_BIP $DOCKER_OPT_MTU $DOCKER_OPT_IPMASQ


Here in this configuration --tlsverify simply turns on TLS verification so that only authorized clients may connect. --tlscacert specifies the location of our CA’s certificate. --tlscert specifies the server certificate location. --tlskey specifies the server key location and -H= means that Docker will listen for connections from anywhere, but it still will not allow any connections that don’t have an authorized client key or certificate.

Now reload the Docker daemon after saving and closing the file, so that it will use our new configuration.

$ sudo systemctl restart docker
$ sudo systemctl status docker

Once the docker service is up running, then run the command below to test our TLS verification.

docker --tlsverify --tlscacert=myca.pem --tlscert=client.pem --tlskey=client-key.pem -H=test.com:2376 info

You will get some basic system information about your Docker host as shown below. This means you just secured your Docker host with TLS. If you get an error, check the logs using systemctl status docker.


You we can access Docker host from anywhere as long as we are connecting using a valid certificate and client key. We can generate and sign as many client certificates as we want for use in a cluster.

4) Installing Shipyard

In this step, we will install Shipyard. Once you have Docker running, it is quite easy to install Shipyard because it ships as Docker images. All you need to do is pull the images from the Docker registry and run the necessary containers. First we will create a data volume container to hold Shipyard’s database data. This container won’t do anything by itself; it is a convenient label for the location of all of Shipyard’s data.

$ docker create --name shipyard-rethinkdb-data shipyard/rethinkdb

Now that the data volume container is created, this is the database engine Shipyard uses to keep track of real-time data from Docker. Now we can launch the database server for Shipyard and link them together.

$ docker run -it -d --name shipyard-rethinkdb --restart=always --volumes-from shipyard-rethinkdb-data -p -p -p shipyard/rethinkdb

This command also ensures that RethinkDB will only listen on localhost. This is a good way to secure this database because it means no one will be able to access it from outside the server.

We’ll be using Shipyard version 2.0.10 because it’s the easiest to configure with Docker TLS. The following command will start a new container that runs Shipyard and links it to the RethinkDB container, allowing them to communicate.

$ docker run -it -p 8080:8080 -d --restart=always --name shipyard --link shipyard-rethinkdb:rethinkdb shipyard/shipyard:2.0.10


5) Accessing Shipyard Web:

Once you have completed your Shipyard setup, open your web browser to visit http://test.com:8080 or http://your_server_ip:8080 to access the Shipyard control panel. You can log in with the default username admin and password shipyard.

shipyard login

Shipyard will prompt you to add a new engine to the cluster. Click the green + ADD button.


You will be presented with some options to fill with name of the new engine and it keys like shown below.

adding-new engine

Once you have updated the required information then click on the ADD button at the bottom of the page. If everything is configured correctly,


If you point to the Shipyard dashboard you will see CPU and RAM stats along with events on its right side.



Shipyard is up and running with secured TLS on CoreOS. You should also be able to configure additional servers with Docker and connect them to your Shipyard instance for management. You’ve also learned how to connect to your Shipyard instance using the GUI, and learned how to deploy new containers on your Docker host with secured TLS using the command line as well as GUI. It helps you in managing your containers and cluster of hosts safely and securely. You can also add a client key and certificate to your local machine so you can remotely manage your Docker cluster from anywhere. That’s all, I hope you have got this article much helpful. Feel free to get back to us in case of any issue.

Would you like to know about Zuul, a CI/CD project gating tool? Download our white paper and get reading!

How to up your DevOps game with Project Gating

Share on Social Media:


Cluster API driver for OpenStack Magnum

Khaled Naser

Public Cloud

9000 MTUs (jumbo frames) in all Public Cloud Regions

Khaled Naser


OpenInfra Summit Berlin 2022 VEXXHOST Recap

Khaled Naser

Go to Top