NVMe/TCP In-Band Authentication - Technology Preview
This is a Beta feature still in development. The feature is not readily available and offers only limited support for evaluative purposes. This release provides mock support for the new APIs/CLIs to use the feature. The commands will update a local database in the API service and will allow creating a new resource - as well as listing, updating, and deleting it. As such, the new APIS and CLIS can be tested extensively; however, with this mock implementation, data is local to a specific API service instance.
NVM Express TP-8006 (NVMe-oF In-Band Authentication) and NVMe Express Base Specification v2.0 add provisions for In-Band Authentication mechanisms applicable to NVMe/TCP, with DH-HMAC-CHAP as the defined initial authentication protocol.
Lightbits will provide support for this, via dedicated functionality to control and manage the set of NVMe hosts (clients) that are allowed to connect to a given NVMe target (Lightbits cluster member), as well as restrict the set of NVMe targets that a given NVMe host will “trust” and allow for connection.
In order to support authentication for specific hosts:
- A new resource named “trusted-host” has been added. Trusted hosts need to be explicitly configured in the Lightbits cluster to allow them to connect to the cluster and for the cluster to connect to them.
- A new command is needed to set the secrets used to authenticate the bidirectional connection (for each such trusted host).
- A new Enable In-Band Authentication command was added.
To use the feature, the following sequence should be followed:
- Enable an In-Band Authentication feature flag. In initial releases, this feature will be released as a technology preview, and support for the functionality must be first enabled. Once in GA, this step can be skipped.
- Create trusted host resources for each host that you want to connect to the cluster.
- Set the secrets for each of these trusted hosts.
- Enable In-Band Authentication.
The order of some of these steps can be changed, but once In-Band Authentication is enabled, only hosts that have the accompanying trusted-host resource with secrets set will be able to connect to the cluster. Enabling the feature flag must be the first step, though you can select to create/set secrets per host one by one, and only then enable In-Band Authentication.
The following sections of this document provide additional detail on each of the APIs. Full details on the APIs/CLIs are available in the Lightbits REST and lbcli documentation.
Enabling In-Band Authentication Feature Support
The InBand authentication feature flag is optional and set to false by default. In order to use this feature, you will first need to enable the in-band-authentication feature flag. This operation only enables availability of In-Band Authentication features. It does not configure the cluster to require authenticated connections (this requires ‘lbcli enable in-band-auth’, which is described later in this article).
This step is only required while this feature is under development, and can be skipped once officially available.
Enable Feature Flag
The entries in the REST API documentation refer to generic feature flags only, and not to each one individually (i.e., /api/v2/featureFlags/{name}/enable).
CLI
lbcli enable feature-flag in-band-authenticationREST
POST /api/v2/featureFlags/inBandAuth/enableTrusted Host
For each host that is allowed to connect to the cluster (and/or for the cluster to connect to), you should create a trusted host resource. This resource will have a unique name for easy access, and a host-nqn identifying the host that this resource is associated with. The trusted host resource is scoped. To allow a host to have access to multiple Lightbits projects, a trusted host resource should be created per project.
A host can only perform NVMe connect to a cluster where it is defined as a trusted host resource. Otherwise, the connection will be refused.
For ease of management, resources can be assigned labels, so that they can be searched for or identified easily. All of the standard CRUD operations are supported for this resource: create, get, list, update, and delete.
CLI
lbcli create trusted-host [flags]lbcli get trusted-host [flags]lbcli list trusted-hosts [flags]lbcli update trusted-host [flags]lbcli delete trusted-host [flags]REST
(create) post: "/api/v2/projects/{projectName}/trustedHosts"(get) get: "/api/v2/projects/{projectName}/trustedHosts/{name}"(list) get: "/api/v2/hosts"(list) get: "/api/v2/projects/{projectName}/trustedHosts"(update) put: "/api/v2/projects/{projectName}/trustedHosts/{name}"(delete) delete: "/api/v2/projects/{projectName}/trustedHosts/{name}"Set/Get Secrets
Once a trusted host has been configured, bi-directional secrets for this host can be configured via CLI/API.
Each trusted host resource has two secrets optionally configured - the host-secret and the target secret. The host-secret is used for authenticating a connection from a host to Lightbits cluster, and the target-secret is used for authenticating a connection from the target (Lightbits cluster member) to a host.
Set/Get secrets are separated from the create/update/get trusted hosts to allow different levels of authorizations for these commands, though in the initial release they share the same access rights configurations.
The secret format might change in the next release, to better align with the requirements of DH-HMAC-CHAP.
CLI
lbcli set trusted-host-secret [flags]lbcli get trusted-host-secret [flags]REST
(set) put: "/api/v2/projects/{projectName}/trustedHostSecrets/{name}"(get) get: "/api/v2/projects/{projectName}/trustedHostSecrets/{name}"Enabling In-Band Authentication
Once trusted hosts are configured, In-Band Authentication can be enabled. This will enable modes of operation per subsystem (currently only a single subsystem is supported, so this would enable operation at the cluster level).
Once enabled, only authenticated hosts can connect to the cluster (subsystem).
CLI
lbcli enable in-band-auth [flags]REST
post: "/api/v2/cluster/inBandAuth/enable"The current configuration can be verified by invoking the get cluster command:
CLI
lbcli get clusterREST
get: "/api/v2/cluster"