Kontena 1.5 Released

Hello Happy Developers! We’re excited to announce that Kontena 1.5.0 is now available.

Release Details

You can find all the release details from the Kontena 1.5 Release Notes.

Highlights

Security Improvements

The Kontena Vault now uses a stronger key derived from the configured VAULT_KEY for encrypting vault secrets. The configured VAULT_KEY was previously truncated to the first 32 bytes, limiting the effective AES-CBC key strength to 128 bits for hexadecimal values, or 192 bits for base64-encoded values. Existing vault secrets will be re-encrypted using the stronger key on upgrade.

The Kontena Vault secrets are now encrypted using a random AES-CBC Initialization Vector (IV) that is randomized for each secret. The configured VAULT_IV was previously used as a static IV shared across all encrypted secrets, but is no longer required. Existing vault secrets will be re-encrypted using randomized IVs on upgrade.

A potential XSS vulnerability in the “kontena master login — remote” code display has been fixed.

Options After Parameters

Commands that accept parameters now accept options also after the parameter. For example, these commands did not work before:

$ kontena stack deploy example-stack --help ERROR: too many arguments $ kontena stack rm example-stack --force ERROR: too many arguments

Note that if you need to use something that looks like an option as a parameter you need to use the common double dash -- option break indicator:

$ kontena master ssh -- ls -al ERROR: Unrecognised option '-l' $ kontena master ssh -- ls -al $ kontena vault write -- SECRET --secret-password--

While mostly invisible to the end-user, the CLI stack registry API client is now using the completely rewritten stack registry and the V2 JSON-API it offers. The registry supports GZip responses, private stacks, server-side stack YAML validation and parsing of the new top level ‘meta:’ fields.

The meta fields can be used to add extra information to stacks published in the registry.

As the CLI HTTP client now supports GZip compressed responses, we have also added the option to enable compression in the Kontena Master API. To enable, set KONTENA_SERVER_GZIP=true in the Master environment.

Drop Support For Ruby 2.1, Build Installer With Embedded Ruby 2.5.0

As the Ruby 2.1 branch has been out of development for almost a year now, it’s time to upgrade if you already didn’t.

The MacOS Kontena CLI installation package is now bundled with Ruby version 2.5.0

Ruby 2.2 is nearing its EOL at the end of March 2018.

Process Multiple Items In One Command

Many of the subcommands can now accept a list of items instead of just one. This is handy in shell scripts and one-liners, for example:

$ kontena vault ls -q | xargs kontena vault rm --force $ kontena vault rm --force $(kontena vault ls -q)

Master Authentication Token Descriptions

You can now add descriptions to the master authentication tokens:

$ kontena master token create -e 0 --description "deploy key" $ kontena master token ls ID TOKEN_TYPE TOKEN_LAST4 EXPIRES_IN SCOPES DESCRIPTION 5a8c275351d1a1001566a4ef bearer f539 never user deploy key

Health Check

The agent now uses the port in health check definition when configuring the load balancer.

Example configuration:

health_check: protocol: http uri: / port: 8000

The health check will now consider HTTP 3XX status codes as healthy.

Logging Service Instance Crash Events

The Kontena service events now include an instance_crash event for service containers that exit unexpectedly. Compared to the existing start_instance events, these events do not get logged for service deploys or manual service restarts.

TIME TYPE MESSAGE ... 2018-02-16T12:38:38.583Z instance_crash service test/client-1 instance exited with code 1, restarting (delay: 0s) (core-01)

Service Affinities

When scheduling a service with an affinity like service==api affinity, only the bare service names were previously matched without considering their stack scope. If multiple stacks had identically named services that match the affinity filter, then all of those external services would have been considered as matching candidates.

You can define a stack scoped affinity rule that matches a service in another stack as service==stack-b/api. A service affinity filter such as service==api will now only match a service named api within the same stack.

The affinity filters can now also include regular expressions such as node!=/^node-(2|3)$/.

Daemon Strategy Node Stickiness

When a service has been deployed using the daemon strategy and a node goes offline, the scheduler now keeps the existing instances on the nodes they were running on already.

NodeAll Online Node 2 Offline Before 1.5 Node 2 Offline With Kontena 1.5 1 instance-1 instance-1 instance-1 2 instance-2 3 instance-3 instance-2 instance-3 4 instance-4 instance-3 instance-2

Let’s Encrypt Certificate Challenges

The Kontena Let’s Encrypt certificate integration now supports http-01 challenges as a replacement for the disabled tls-sni-01 challenges.

About Kontena

Kontena provides the most easy-to-use, fully integrated solution for DevOps and software development teams to deploy, run, monitor and operate containers on the cloud. The underlying Kontena Platform technology is open source and available under Apache 2.0 license. It is used by hundreds of startups and software development teams working for some of the biggest enterprises in the world. www.kontena.io.

Image Credits: Chuttersnap on Unsplash.

Originally published at blog.kontena.io on February 28, 2018.