Traffic Authorization can be used to regulate HTTP/HTTPS traffic between services. This involves a forwarder, gatekeeper, and token broker. This allows inbound and outbound traffic to be verified by the token broker in order to ensure that traffic between services is secure. Each container runs a gatekeeper that is used to intercept all the HTTP/HTTPS inbound traffic and verifies its authenticity from a token that is found in the authorization header. The forwarder also runs on each container, and like the gatekeeper, this also intercepts traffic; however, instead of intercepting inbound traffic, it intercepts outbound traffic and places the token on the authorization header. These tokens are issues from the token broker. These tokens can also be cached to save time and minimize the impact of latency. Let's break it down into a series of steps, as shown in the following:

As you can see, this applies extra authorizations on both inbound and outbound requests. As we will see in the next section, you can also use Summon along with Traffic Authorization to use shared secrets that are available once they are used, but go away once the application has completed its actions.

For more information about Traffic Authorization and Docker, visit https://blog.conjur.net/securing-docker-with-secrets-and-dynamic-traffic-authorization.

Summon is a command-line tool and is used to help pass along secrets or things you don't want exposed, such as passwords or environmental variables and then these secrets are disposed upon exiting the process. This is great as once the secret is used and the process exits, the secret no longer exists. This means the secret isn't lingering around until it is either removed manually or discovered by an attacker for malicious use. Let's take a look at how to utilize Summon.

Summon typically uses three files: a secrets.yml file, script used to perform the action or task, and Dockerfile. As you have learned previously, or based on your current Docker experience, the Dockerfile is the basis of what helps in building your containers and has instructions on how to set up the container, what to install, what to configure, and so on.

One great example have for the usage of Summon is to be able to deploy your AWS credentials to a container. For utilizing AWS CLI, you need a few key pieces of information that should be kept secret. These two pieces of information are your AWS Access Key ID and AWS Secret Access Key. With these two pieces of information, you can manipulate someone's AWS account and perform actions within this account. Let's take a look at the contents of one of these files, the secrets.yml file:

secrets.yml
AWS_ACCESS_KEY_ID: !var $env/aws_access_key_id
AWS_SECRET_ACCESS_KEY: !var $env/aws_secret_access_key

The -D option is used to substitute values while $env is an example of a substitution variable, therefore, the options can be interchanged.

In the preceding content, we can see that we want to pass along these two values into our application. With this file, the script file you want to deploy, and the Dockerfile, you are now ready to build your application.

We simply utilize the docker build command inside the folder that has our three files in it:

$ docker build -t scottpgallagher/aws-deploy .

Next, we need to install Summon, which can be done with a simple curl command, as follows:

$ curl -sSL https://raw.githubusercontent.com/conjurinc/summon/master/install.sh | bash

Now that we have Summon installed, we need to run the container with Summon and pass along our secret values (note that this will only work on OS X):

$ security add-generic-password -s "summon" -a "aws_access_key_id" -w "ACESS_KEY_ID"
$ security add-generic-password -s "summon" -a "aws_secret_access_key" -w "SECRET_ACCESS_KEY"

Now we are ready to run Docker with Summon in order to pass along these credentials to the container:

$ summon -p ring.py docker run —env-file @ENVFILE aws-deploy

You can also view the values that you have passed along by using the following cat command:

$ summon -p ring.py cat @SUMMONENVFILE
aws_access_key_id=ACESS_KEY_ID
aws_secret_access_key=SECRET_ACCESS_KEY

The @SUMMONENVFILE is a memory-mapped file that contains the values from the secrets.yml file.

For more information and to see other options to utilize Summon, visit https://conjurinc.github.io/summon/#examples.

sVirt is part of the SELinux implementation, but it is typically turned off as most view it as a roadblock. The only roadblock should be learning sVirt and SELinux.

sVirt is an open source community project that implements MAC security for Linux-based virtualization. A reason you would want to implement sVirt is to improve the security as well as harden the system against any bugs that might exist in the hypervisor. This will help in eliminating any attack vectors that might be aimed towards the virtual machine or host.

Remember that all containers on a Docker host share the usage of the Linux kernel that is running on the Docker host. If there is an exploit to this Linux kernel on the host, then all containers running on this Docker host have the potential to be easily compromised. If you implement sVirt and a container is compromised, there is no way for the compromise to reach your Docker host and then out to other Docker containers.

sVirt utilizes labels in the same way as SELinux. The following table is a list of these labels and their descriptions: