Hardware Key Support

As of v1.5.0 the Floating Server supports using hardware keys (Yubikey) as a license protection method. If a license requires the usage of a hardware key a valid provisioned key must be accessible from the Pod running the floating server.

Limitations

• Only one replica running at the same time - no HA support as of now
• The pod running the floating server is tied to the node which has the key connected

Requirements

• Kubernetes node in which a yubikey can be inserted. If running in a VM, the hypervisor must have USB passthrough support and configured.
• A way to passthrough the hardware key to the pod running the floating server. Akri https://docs.akri.sh/ Generic Device Plugin https://github.com/squat/generic-device-plugin

General

Getting the udev information for the device.

1

Identify the device on the USB bus

First get the device bus and device ID with lsusb.

2

Build the device path

Combine them into /dev/bus/usb/<bus_id>/<device_id>.

3

Query udev attributes

Using udevadm get the attributes for the device:

udevadm info --attribute-walk --path=$(udevadm info --query=path /dev/bus/usb/<bus_id>/<device_id>)

Usually for Yubikeys these attributes are enough. But results may vary depending on system.

Example attribute match: SUBSYSTEM=="usb", ATTR{idProduct}=="0407", ATTR{idVendor}=="1050"

Setting up the floating server helm chart for use with a hardware key

• Set .Values.hardwareKeySupport = true — disables replicas, values for .Values.replica will be ignored and set to 1

Example - Akri plugin

1

Install and configure Akri with udev discovery: https://docs.akri.sh/user-guide/getting-started

2

Add a udev rule for Yubikey as a separate configuration or as part of the helm chart values. (Examples below)

3

Add the akri flags to .Values.resources.limits and .Values.resources.requirments

Example 1 - akri configmap

akri-yubikey-configuration.yaml

apiVersion: akri.sh/v0
kind: Configuration
metadata:
  name: akri-yubikey # Name we later use to get the resource
spec:
  capacity: 1
  discoveryHandler:
    discoveryDetails: |
      groupRecursive: true # Recommended unless using very exact udev rules
      udevRules:
      # udev attributes we gathered from udevadm
       - SUBSYSTEM=="usb", ATTR{idProduct}=="0407", ATTR{idVendor}=="1050"
    name: udev

Example 2 - setting udev rules via helm values - akri chart

values.yaml (akri)

udev:
  configuration:
    # enabled defines whether to load a udev configuration
    enabled: true
    # name is the Kubernetes resource name that will be created for this
    # udev configuration
    name: akri-yubikey
    # brokerProperties is a map of properties that will be passed to any instances
    # created as a result of applying this udev configuration
    discoveryDetails:
      # groupRecursive defines whether to group discovered parent/children under the same instance
      groupRecursive: true
      # udevRules is the list of udev rules used to find instances created as a result of
      # applying this udev configuration
      udevRules:
        - SUBSYSTEM=="usb", ATTR{idProduct}=="0407", ATTR{idVendor}=="1050"

Example 3 - resource values for floating server chart

values.yaml (floating server)

hardwareKeySupport: true

resources:
  requests:
    cpu: 50m
    memory: 64Mi
    akri.sh/akri-yubikey: "1"
  limits:
   # cpu: 200m
   # memory: 256Mi
    akri.sh/akri-yubikey: "1"