Application containers are gaining traction in the IT community. However, at the last Container Summit in NYC, Dave Bartoletti of Forrester Research cited that 53% of companies claim that security is the top deployment concern for containers. Although the umbrella of “security” is quite broad, one of the more fundamental challenges in deploying containerized applications is to provide controlled access to data. To date, there are no security mechanisms in place to protect volume data. We considered releasing a generic authentication and authorization framework for Docker volumes, but it quickly became clear that the infrastructure itself must provide enforcement of security policies. Anything implemented at the host level would only be capable of providing discretionary access controls, leaving a measurable security gap between the container host and the infrastructure.

Authenticated Volumes To help improve container data security, we are excited to bring Authenticated Volumes to the container world. Authenticated Volumes leverage multi-factor authentication and single-use credentials to provide controlled access to data volumes. Our current implementation supports Google Authenticator (timer-based) and Yubikey (counter-based) one-time passwords. Volume access controls are multi-tenant secure, multi-host compatible, and provide a full audit trail for compliance purposes. From a security perspective, Volume Authentication ensures that data volumes cannot be attached to a container host without proper authentication and that data volumes cannot be accessed or discovered via direct access to the storage infrastructure. On the container host, the use of one-time credentials provides protection against vulnerabilities associated with state that is recorded as a byproduct of normal container management (i.e. caches, environment variables, layers, etc. ).

Docker Volume Workflow Volume Creation Authenticated volumes must be created explicitly using the ‘docker volume create’ command. To authenticate, a user must supply a valid one-time password as a volume option. Authentication is Required on Volume Creation # docker volume create --driver blockbridge --name auth-vol \ --opt profile=user77 --opt otp=186495 auth-vol

Volume Mount Authenticated volumes are attached to a container using standard interfaces. To authenticate access, append a valid OTP to the volume name inline of your run command. Note that the use of a one-time passphrase is essential to providing protection against replay attacks. Authentication is Required on Attach # docker run -v auth-vol,otp=249751:/data busybox sh / # df /data Filesystem 1K-blocks Used Available Use% Mounted on /dev/blockbridge/auth-vol/DSK1962394C40626660 1046496 33056 1013440 3% /data / #

Volume Removal To prevent unauthorized destruction of data, volume removal requires authentication as well. To authenticate, append a valid OTP to the volume name inline of the volume remove command, as shown below: Authentication is Required on Removal # docker volume rm auth-vol,otp=339305 auth-vol,otp=339305

Preparing Your Environment Authenticated Volumes leverage standard Docker interfaces and do not require changes to container applications. To use them, you do need to configure storage-level authentication using one of our management interfaces (i.e. API, CLT, GUI). The examples below use our platform agnostic command line tools (i.e. CLT).

Persistent Authorization A Persistent Authorization, commonly referred to as an API access token, provides a way to establish identity, perform authentication and scope permissions. You can create persistent authorizations on a per-tenant or per-user basis to implement multiple authentication domains and enforce resource isolation. For authenticated volumes, create a persistent authorization using the CLT as shown below: Create Tenant-specific Persistent Authorization with Multi-Factor Authentication Policy # bb authorization create --restrict none --enforce-two-factor == Created authorization: ATH4762D94C40626600 serial ATH4762D94C40626600 account user77 (ACT0762694C406264C0) user user77 (USR1B62394C406264C0) enabled yes created at 2016-02-26 22:57:03 +0000 access type online token suffix CPBNEZEw restrict none enforce 2-factor true == Access Token access token 1/GbbAjwTRE1J/hnD1HyNd4pjQi96JVDpExK2hf+JS9WhJtMCPBNEZEw *** Remember to record your access token!

One-Time Passphrase A one-time passphrase provides authentication materials that are valid for a single API session. OTP algorithms use pseudorandomness (ie. secure hash functions) to provide protection against replay attacks. In the example below, we use Google Authenticator. GA is an open-source implementation of timer-synchronized OTP: each OTP is valid for 30 seconds. For authenticated volumes, configure OTP as shown below: Configure Multi-factor Authentication (Google Authenticator OTP) # bb user update --user user77 --two-factor google --qrcode ansi Scan the QR code above with Google Authenticator. Enter generated OTP: 035645

Storage Profile A storage profile provides a way to templatize parameters used during volume creation. For authenticated volumes, it provides a convenient way to associate tenant credentials with a volume type. In the example below, we create a storage profile specifically for ‘user77’ . By associating a persistent authorization with the storage profile, all data and management operations performed by the volume driver are performed in the context of the “user77” tenant. Note that the policy applied to the token requires multi-factor authorization. Define Tenant-specific Docker Storage Profile # docker exec blockbridge-volume-driver profile create \ --name user77 --user user77 --capacity 1GiB \ --access-token 1/GbbAjwTRE1J/hnD1HyNd4pjQi96JVDpExK2hf+JS9WhJtMCPBNEZEw [ { "name": "user77", "type": "autovol", "user": "user77", "capacity": "1GiB", "token_suffix": "CPBNEZEw" } ]