Security Considerations for Nimble Docker Volume Plugin

[zhonghuiwen90]

We have a single array nimble store which we currently use with VSphere. But with Docker in the picture, we would like to have docker volume creation done on the docker host

In terms of security with multi-tenancy in mind, we would like all actions performed via Nimble Docker Volume Plugin to be isolated from the rest of the array.

1) Is it possible to create a nimble user account with operator access and use that account when setting up the Nimble Docker Volume Plugin? We would like to limit the docker host administrator from accidentally deleting volumes

2) I understand that if we want to force all docker volumes to be isolated to a nimble folder to limit IOPS & space, we can enforce that using the volume-driver.json overrides to a folder. But is there any way to limit a user account to a nimble folder?

3) Will the docker host administrator be able to mount volumes that are outside of the specified folder in the volume-driver.json?

[MichaelMattsson · Accepted solution]

Thanks for kicking the tires on the HPE Nimble Storage Volume Plugin for Docker! The plugin does not support secure multi-tenancy, only application multi-tenancy. The plugin require "poweruser" access if I recall correctly and that gives whomever have access to those credentials unfettered access to all resources on the Nimble array.

The only way to create a separation of privileges is to have the storage administrator install the Docker Volume Plugin and manage the Docker host and add users to the "docker" group on the Docker host to allow users to create/delete volumes. There's still room for malicious intent but it should provide enough isolation for trusted users.

[zhonghuiwen90]

Haha, thanks @MichaelMattsson  for responding to the tyre kicking  

To summarize from what i understand from you

1) Nimble Storage administrator will install the docker volume plugin, remove his poweruser credentials from the docker host. This prevents docker host users from maliciously using the credentials.

2) Nimble Storage administrator will specify a folder override to isolate volumes to a folder. Meaning that if an application owner performs a docker stack deploy with a named volume, the volume will only be created in the folder specified by the nimble admin.

3) Nimble Docker volume plugin only has the capabiity to create/delete/import/clone/list volumes , there would actually be no way to perform destructive actions (e.g. remove an array) even for the nimble administrator through the docker host.

[MichaelMattsson]

1) Nimble Storage administrator will install the docker volume plugin, remove his poweruser credentials from the docker host. This prevents docker host users from maliciously using the credentials.

Yes, the PROVIDER_USERNAME and PROVIDER_PASSWORD may be removed after the first authentication has been completed. Like this:

docker plugin set nimble PROVIDER_IP=192.168.59.128 PROVIDER_USERNAME=admin PROVIDER_PASSWORD=admin
docker plugin enable nimble
docker plugin disable nimble
docker plugin set nimble PROVIDER_USERNAME="true" PROVIDER_PASSWORD="true"
docker plugin enable nimble

Make sure the plugin is not reporting any errors while setting the initial credentials. This procedure is described here.

2) Nimble Storage administrator will specify a folder override to isolate volumes to a folder. Meaning that if an application owner performs a docker stack deploy with a named volume, the volume will only be created in the folder specified by the nimble admin.

Yes. This is correct. Your /etc/hpe-storage/volume-driver.json will look like this on the Docker host (this file is considered for each volume request and may be edited during runtime of the plugin, except the global section):

{
    "global":   {},
    "defaults": {
                 "sizeInGiB":"10",
                 "limitIOPS":"-1",
                 "limitMBPS":"-1",
                 "perfPolicy": "DockerDefault",
                 "mountConflictDelay": 120
                },
    "overrides":{
                 "folder": "docker-folder"                
    }
}

3) Nimble Docker volume plugin only has the capabiity to create/delete/import/clone/list volumes , there would actually be no way to perform destructive actions (e.g. remove an array) even for the nimble administrator through the docker host.

All operations performed by the plugin may only be performed on volumes in the folder "docker-folder". Even if a malicious attacker gets access to the client certificates in /etc/hpe-storage, the attacker only have access to the Container Provider that runs on the array, which has very limited access to API calls only needed by the Docker Volume Plugin. The absolute worst that theoretically happen is that the attacker clone a volume from a different folder and for that the attacker needs to know the name of the source volume. A malicious user/attacker may also carry out DoS attacks but I think you'll have bigger problems to deal with if that is happening.

[zhonghuiwen90]

@MichaelMattsson we understand that the nimble docker volume plugin requires the Nimble array data IP's and docker host adapters used for iSCSI to be in the same network. So the way forward would be to add a route between the 2 networks.

In terms of security risk, are there any things we need to consider? Could the docker hosts be a point of vulnerability and are there any recommendations for securing them?

[MichaelMattsson]

Yes, data and control plane traffic needs to be routable between docker hosts and the array. Standard security practices host hardening applies.