Krill has an embedded web server, and saves its status on disk as json files. Krill does not depend on any database, but will need to be configured and told where on the system its working directory is.
You can have a look at all possible configuration directives in
the packaged version of the default configuration file. This file
can be found, relative to where you cloned krill, under:
You will notice that this file contains comments only. I.e. it
documents default configuration settings. In order to override
the Krill config you should create your own
and use the
--config directive when you start
krilld --config <path-to-config>
You will need to generate your own secret token (password) before you can run krill. If you do not supply a token, Krill will refuse to start and complain with the following message:
You MUST provide a value for the master API key, either by setting "auth_token" in the config file, or by setting the KRILL_AUTH_TOKEN environment variable.
There is no default token, because we want to avoid that people run with default passwords. So, make up a nice one, and either add it to your config file, or use the ENV variable if you prefer.
Proxy and HTTPS¶
Krill uses HTTPS and refuses to do plain HTTP. In theory Krill should be able to use a key pair and corresponding certificate signed by a web TA. However, this is untested.
By default Krill will generate a 2048 bit RSA key and self-signed certificate when it’s first started.
We recommend, at least for now, that you run Krill with this default, and use a proxy server such as nginx if you intend to make Krill available to the internet. Industry standard proxy servers such as nginx are much better suited to deal with the sometimes-not-so-well-meaning people on the internet, and implement best practices regarding HTTPS.
Also, setting up a widely accepted HTTPS certificate, e.g. through Letsencrypt, is well documented for these servers.
Krill uses defaults that are sensible for development. Some of these may also be fine if you are testing Krill locally. However you should review the following.
Public IP and Port¶
We recommend that you keep the following settings, and use a proxy server if you want to expose Krill to other users:
# Specify the ip address and port number that the server will use. #ip = "localhost" #port = 3000
By default Krill will expect a directory called
data relative to its
# Specify the directory where the publication server will store its data. # Note that clustering through a shared data directory is not supported. # But, we plan to look into a proper clustering solution later. #data_dir = "./data"
You should probably change this to use an absolute path instead.
Krill will create a number of subdirectories under this
data_dir for various
|cas||The state of all CAs in this Krill instance.|
|ssl||The HTTPS key pair and certificate.|
|proxy||The state of remote publishers. (will be deprecated)|
|publishers||The state of all publishers in this Krill instance.|
|repo-server||The state of the repository server (client info, and published objects)|
|repo/rsync/||Published RPKI objects that should be made available through an rsync server.|
|repo/rrdp/||Published RPKI objects in RRDP (RFC8182) XML format.|
Service and Certificate URIs¶
rsync_base setting should match the URI of your rsync server, as this is put on
any certificates, manifests and ROAs that Krill will create. The
is used to determine the URI for the RRDP notification file used on certificates, but it’s
also used to determine the public URI that will be included in responses to delegated
remote child CAs that you may delegate resources to:
# Specify the base rsync repository for this server. Publishers will get # a base URI that is based on the 'publisher_handle' in the XML file. # # Note, you should set up an rsync daemon to expose $data_dir/rsync to serve # this data. The uri defined here should match the module name in your rsync # configuration. #rsync_base = "rsync://localhost/repo/" # Specify the base public URI to this service. Other URIs will be derived # from this: # <BASE_URI>rrdp/notification.xml (pub point or rrdp) # <BASE_URI>rrdp/<session>/<version>/snapshot.xml # <BASE_URI>rrdp/<session>/<version>/delta.xml # <BASE_URI>ta/ta.cer (on TAL for embedded TA) # <BASE_URI>rfc6492 (for remote children) # # MUST end with a slash. #service_uri = "http://localhost:3000/"
Embedded Trust Anchor¶
For testing purposes you may want to run Krill with an embedded test Trust Anchor (TA). Using a TA will allow you to create your own test Certificate Authority (CA) and with a locally signed certificate. This is useful when learning how to deploy and use Krill.
To use the embedded TA add the following line to your
use_ta = true
The Trust Anchor Locator (TAL) for this TA can be retrieved from
You can use this TAL in a Relying Party (RP) tool, such as routinator, to validate the ROAs you create. But, note that no one else will have this TAL, so this is useful for testing only.
At this moment there is no way to disable the embedded TA once it’s created. We may add this later, but for now we recommend that you use this option only on instances that you are prepared to use for testing only.