Configuring Token Authentication

This guide requires an Anka Enterprise or Enterprise Plus license.

Starting in 1.19.0 of the Anka Build Cloud, there are two options for securing the communication with the Build Cloud Controller & Registry:

1. Setting the Root Token, protecting the Controller API and UI.

2. Generating a user private key which is then used to request temporary session tokens by the client. These session tokens allow access to the API to perform various tasks.

However, there are several license specific differences that should be noted before you begin:

• Enterprise: By default, any tokens you generate (root or user) always have full access to the API.
• Enterprise Plus: By default, only the root token has full access to the API. User tokens must be created with a group attached and permissions added for the group.

We recommend disjoining all but one node. One node must stay joined to ensure the Build Cloud has the proper license attached. You can rejoin it later once you’re configured and you’ve rejoined all of your other nodes.

Protecting your cloud with RTA (Root Token Auth)

Enabling root token authentication is a simple process. The root user has what we call “superuser” (full) access to the controller, API (basic auth), etc.

How to configure RTA

MacOS Package

Edit /usr/local/bin/anka-controllerd and add:

export ANKA_ENABLE_AUTH="true"
export ANKA_ROOT_TOKEN="{min10chartoken}"

The macOS package has no way to set tokens or auth for either the controller or registry. It will be enabled for both if the ENV is set to true.

The root token must be at least 10 characters long.

Linux/Docker Package

With our docker package, each service is split up into its own container. You can enable a root token for either the controller, registry, or both.

Edit the docker-compose.yml and add both ANKA_ENABLE_AUTH and ANKA_ROOT_TOKEN environment variables:

. . .

anka-controller:
   build:
      context: .
      dockerfile: anka-controller.docker
   ports:
      - "80:80"
   volumes:
     # Path to ssl certificates directory
     - /home/ubuntu:/mnt/cert
   depends_on:
      - etcd
   restart: always
   environment:
     ANKA_ENABLE_AUTH: "true"
     ANKA_ROOT_TOKEN: "1111111111"
     # ANKA_ENABLE_API_KEYS="true"

anka-registry:
   build:
      context: .
      dockerfile: anka-registry.docker
   ports:
      - "8089:8089"
   . . .
   environment:
     ANKA_ENABLE_AUTH: "true"
     ANKA_ROOT_TOKEN: "1111111111"
     # ANKA_ENABLE_API_KEYS="true"
. . .

Testing RTA

If everything is configured correctly, you can visit your Controller Dashboard and a login box should appear.

Enter the token you specified and ensure that it logs you in.

Finally, you can test the API using:

❯ curl -H "Authorization: Basic $(echo -ne "root:1111111111" | base64)" http://anka.registry:8089/registry/status
{"status":"OK","body":{"status":"Running","version":"1.19.0-309d8150"},"message":""}

Protecting your cloud with UAK (User API Keys)

How to configure UAK

1. Follow the same instruction from the above root token section, but also include ANKA_ENABLE_API_KEYS set to true.

2. Use the API to generate a user key for the controller and also the registry.

3. You can now use the key and ID to communicate with the Controller or Registry.

Joining Nodes with your UAK

❯ sudo ankacluster join http://anka.controller:8090 --groups "gitlab-test-group-env" --reserve-space 10GB --api-key-id "nathan" --api-key-string "$ANKA_API_KEY_STRING"
I0920 15:31:15.008778   77147 factory.go:75] Default http client using API Key authentication
Testing connection to the controller...: Ok
Testing connection to the registry...: Ok
Success!
I0920 15:31:37.300568   77147 factory.go:75] Default http client using API Key authentication
Anka Cloud Cluster join success

At the moment the ankacluster command does not support ENVs.

Instead of passing the private key base64 as a string (--api-key-string), you can specify the path to the key file with --api-key-file.

Controller and Registry communication with your UAK

Should the Registry be protected by authentication and User API Keys, the Controller requires its own key for registry API calls. Once generated, you need to specify the ANKA_API_KEY_ID and ANKA_API_KEY_STRING (or file) ENVs described in the Configuration Reference.

Token Authentication Protocol (TAP)

The following API is only useful if you’d like to build your own client to request and renew session tokens from UAKs.

• Highly recommended to integrate with HTTPS
• Base64 uses safe url encoding
• Key length is 2048, Hashing algorithm SHA256, OAEP padding
• Private key format is PEM PKCS#1
• Public key format is PKIX, ASN.1 DER

This communication protocol is for user authentication using asymmetric encryption. The API is separate from the usual /api/v1/.

Authentication flow

1. A public key is stored on the server along with some unique identifier.
2. A client sends the first phase of the authentication: POST /tap/v1/hand -d '{"id": "<USER-ID>" }'
3. The server generates a random string, encrypts it with the client’s public key, encodes it in base64 and passes it back to the client in the response body
4. The client decodes and decrypts the response and sends the following the second phase of the authentication: POST /tap/v1/shake -d '{"id": "<USER-ID>", "secret": "<SECRET-STRING>" }'
5. The server successfully authenticates the client and returns the following object (base64 encoded) in the response body: { "id": <USER-IDENTIFIER>, "data": <GENERIC-OBJECT> }
6. The “data” field is a generic object, and can be customized for specific needs

Putting it all together

When an API Key is created, the public key and id are stored and later used in the TAP authentication protocol.

Upon a successful authentication with the TAP protocol, a session is created and the generic data object that is returned includes the following data:

{
  "userName": <USER-IDENTIFIER>
  "sessionId": <SESSION-ID>
  "token": <SESSION-TOKEN>
}

This object, encoded in JSON and base64 is what the user supplies in the HTTP Authorization header, with the Bearer prefix, for future requests.

Managing User/Group Permissions (Authorization)

Your --api-key-id is the username.

Permission groups are configurable from your Controller’s https://<controller address>/admin/ui page.

This feature requires Enterprise Plus. The regular enterprise license automatically adds all permissions to each certificate that is used and gives no control over them.

Within the Controller’s Permission administration panel, we use O= as the Group Name and CN= as the Username.

Both O= and CN= are required.

Spaces are supported in O= and Anka Build Cloud Controller version >= 1.10.

This requires that you’ve enabled Root Token Authentication, giving you super user access to the controller UI and permissions.

The permission groups here differ from the groups you assign to nodes within the Controller UI.

The Available Permissions list will display all of the permissions we can assign to the group (see below for the full list). These permissions will allow plugins/users (like Jenkins) to communicate with the Controller & Registry:

Minimum Recommended Permissions

• get_groups
• get_registry_disk_info
• list_images
• list_nodes
• list_vms
• save_image
• start_vm
• terminate_vm
• update_vm
• view_logs

Controller Permissions

Registry Permissions