docker-kdc

Docker container generator for a Heimdal Kerberos 5 KDC.

The intension here is to ease the first steps with Kerberos while also allowing a customized, automated setup for development or test integration. Usable on plain Linux as well as on OSX.

Dependencies

• Docker
• jq 1.4

Linux specific dependency

• Heimdal Kerberos 5

OSX specific dependency

• boot2docker

Usage

Check your configuration

The default configuration is likely to be fine for your first steps, validate it using the config command.

./kdc config

You will receive a list of relevant configuration information. The defaults are derived from your hosts' configuration to allow for a quick test setup.

Example output: ./kdc config

System
  fqdn:      hostname.domain.name
KDC
  nat:       127.0.0.1
  port:      48088
Kerberos
  domain:    domain.name
  realm:     DOMAIN.NAME
  principal: tillt/hostname.domain.name@DOMAIN.NAME, password: matilda

Build the docker image

./kdc build

This will render the image which is based on plain ubuntu 14.04. Additionally the packages heimdal-kdc as well as libsasl2-modules-gssapi-heimdal are installed. The latter is useful only if you extend this container image by further applications making use of Kerberos authentication via SASL2's GSSAPI.

Run the container

./kdc start

On OSX, this step starts by setting up the VM (via boot2docker). Then, on all host systems, the container is started in detached mode, allowing you to keep on working with this shell without having to fork another process. The container name is directly derived from the hostname supplied via the configuration (see Configuration).

Watch the KDC server log file

docker exec -it kdc tail -f /var/log/heimdal-kdc.log

Run a quick test

./kdc test

On OSX, this first checks if the VM is active. Then, on all hosts systems, a network connection to the KDC is attempted.

Prepare the environment

$(./kdc shellinit)

A Kerberos client needs access to a configuration file. To prevent having to edit the system wide configuration file (/etc/krb5.conf) a local, minimal version is rendered and supplied once the container has gotten started. Additionally, the keytab also gets exported and hence needs to be accessible for clients making use of password-less authentication. To make use of the files, environment variables that are interpreted by Kerberos clients are prepared.

Render a ticket supplying the principal password

kinit tillt/hostname.example.com@EXAMPLE.COM

Password: matilda

Check the ticket

klist

On OSX you could also use the Ticket Viewer to check the details of the issued ticket (open "/System/Library/CoreServices/Ticket Viewer.app").

Example output: klist

Credentials cache: API:42926CE1-63E2-4C66-B2D7-00B2F198182F
        Principal: tillt/hostname.example.com@EXAMPLE.COM

  Issued                Expires               Principal
Nov 26 11:06:25 2014  Nov 26 21:06:25 2014  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Remove the ticket

kdestroy

Check the content of the keytab

ktutil --keytab=krb5.keytab list

Example output: ktutil --keytab=krb5.keytab list

krb5.keytab:

Vno  Type                     Principal                              Aliases
  1  aes256-cts-hmac-sha1-96  tillt/hostname.example.com@EXAMPLE.COM
  1  des3-cbc-sha1            tillt/hostname.example.com@EXAMPLE.COM
  1  arcfour-hmac-md5         tillt/hostname.example.com@EXAMPLE.COM

Render a ticket using keytab based authentication

kinit -kt krb5.keytab tillt/hostname.example.com@EXAMPLE.COM

Check the ticket

klist

[...]

Stop the container

./kdc stop

This will stop the KDC server, stop and remove the container and additionally remove the temporary keytab and configuration files.

Customize your configuration

You may use environment variables and/or a JSON configuration file for customizing the setup. The default filename for the JSON file is kdc.json but may be configured by the environment variable KDC_CONFIG.

The default configuration is most likely good enough for your first experiments.

Kerberos principal

Note: using a configuration file allows setting up multiple principals (via principals[ ].id).

Kerberos password

Note: using a configuration file allows setting up multiple passwords (via principals[ ].password).

Kerberos client

Note: when no principals are defined via configuration file, KDC_CLIENT is used to create a full service principal (schema: KDC_PRINCIPAL / KDC_CLIENT . KDC_DOMAIN_NAME @ KDC_REALM_NAME ).

KDC hostname

External KDC IP

Note: this value gets overridden by the kdc script on OSX to allow for connecting to the boot2docker VM. You shouldn't really need to override this in any case.

External KDC port

Kerberos domain name

Kerberos realm name

Note: it is common practice to simply use the domain-name but all capitalized for this.

Configuration filename

templates/kdc.json

{
  "principals": [
    {
      "id": "tillt/host.example.com@EXAMPLE.COM",
      "password": "herbert"
    },
    {
      "id": "tillt@EXAMPLE.COM",
      "password": "herbert"
    }
  ],
  "domain": "example.com",
  "realm": "EXAMPLE.COM",
  "ip": "127.0.0.1",
  "port": 48088
}

Reference

./kdc start|stop|build|clean|config|shellinit

build

Builds the docker image.

start

Starts the container in detached mode while also producing a Kerberos configuration file (krb5.conf) as well as a Kerberos keytab (krb5.keytab) locally.

Note that the keytab is only readable/usable by the current user unless you change its access rights which is not recommended for production environments.

stop

Stops the container and deletes krb5.conf as well as krb5.keytab.

clean

Removes the docker image.

config

Shows relevant configuration information.

test

Checks if the KDC is reachable and accepting connections.

shellinit

Renders the environment variables needed for using the KDC. KRB5_CONFIG points towards the temporary configuration file. KRB5_KTNAME points towards the temporary keytab file.

TODO

• strip down base image to squeeze out some space
• refactor code into something less convoluted
• allow for an admin server, not just the KDC

Credits

This script was inspired by some work of a co-worker of mine, Matthias Veit. Matthias did the hard work of finding out how to properly route docker ports on boot2docker hosts.

Author

• Till Toenshoff (@ttoenshoff)