# Akri – Configuring Device Credentials Exploration

## Overview
Akri is A Kubernetes Resource Interface for the Edge. It eases the use of IoT devices by applications running on Kubernetes Clusters on the Edge. Akri is currently pre-release and is not used in production scenarios. Before Akri can be used in production, it must have an established flow for discovering only authenticated devices. This requires provisioning devices with credentials and securely transferring credentials from a secret store to Akri’s Discovery Handlers. This ensures that Akri only creates Kubernetes resources for authenticated devices.

In the past, Akri has emphasized its use in discovering newly connected devices – implying that this is a zero-touch scenario where an operator simply turns on a device. It has become more and more clear that this is not a use case for the edge. In fact, most operators know what devices are on the network, and having a device registry is necessary to achieving Zero Trust security. That registry can be used to keep note of device lifecycles, ensuring device updates and automatic credential rotation. This can be explored in more depth in [Microsoft’s Zero Trust IoT Security White Paper](https://azure.microsoft.com/mediahandler/files/resourcefiles/zero-trust-cybersecurity-for-the-internet-of-things). With this in mind, it can be assumed that in production settings, operators have an inventory (or registry) of the devices with which Akri will interact. The purpose of Akri is to ease connecting these devices to Kubernetes applications. Akri manages the creation of Kubernetes resources for the devices and restricts the number of workloads that each device can use (if desired). It makes using these devices declarative. It should also enable using these devices in a secure manner.

This document aims to start a discussion on how to extend Akri to only discover authenticated devices.

## Current support in Akri
Currently, Akri does not support discovering authenticated devices. [Akri’s original security overview](https://github.com/project-akri/akri-docs/blob/main/proposals/security.md) puts the onus on the broker (the workloads automatically deployed by Akri) to authenticate with the device. The [OPC UA demo](https://docs.akri.sh/demos/opc-thermometer-demo) walks through how to mount an X.509v3 certificate into broker Pods through Kubernetes secrets. Then, the brokers can authenticate with the OPC UA servers due to shared intermediate certificates. However, all the brokers have the same certificates, which is not ideal. Furthermore, an authentication check should happen earlier. In the case that the broker cannot authenticate with the device, it cannot report this information back to Akri, and the associated Akri Instance and Kubernetes resource lives on.

## Goals/Non-Goals
### Goals
- Plug into PKI, attestation, and secret store solutions
- Discovery Handler can authenticate devices before marking them as discovered.
- Akri/ Discovery Handlers should be able to get renewed certificates (as devices certificates are renewed)
- A no-security mode can be enabled – this is suitable for demo purposes and locked down networks.
- Credentials can be passed to brokers such that they can authenticate the devices being used
- Support or evolve to support a variety of credential types (x509 certs, user/pass pair, TPM, etc.)
### Non-goals
- Akri implements its own PKI, attestation, and secret store solution

## Customer Scenarios
Akri aims to be the standard way to interact with IoT devices from a Kubernetes cluster. However, to be a standard, it must support a variety of different IoT devices, which support different methods of authentication. Ideally, Akri’s infrastructure supports “pluggable” authentication scenarios that are as Kubernetes-native as possible. A list of authentication methods used in IoT devices and protocols should be made. The following table can serve as a starting point.

| Protocol | Credential[s] | Notes |
| ----------- | ----------- | -------- |
| OPC UA | X.509v3 (PKI) | Shared intermediate auth |
| ONVIF | User/Pass, X.509v3 | |

A key part of assessing a strong identity for devices is using password-less authentication. The most prevalent and standardized way to do this is with X.509v3 certificates. Akri could focus on supporting X.509 authentication to start. X.509 certificates also provide opportunities for scaling certificate usage as access can often be granted between certificates matched by a trusted intermediate certificate authority, as done in Akri’s current OPC UA implementation for broker authentication.

## Scenario 1: Standard PKI based Authentication

Kubernetes secrets could be mounted in the Akri Discovery Handler containing the PKI needed to authenticate devices that are expected to be discovered.

## Scenario 2: Unique Device Credentials and No Certificate Chain

How can Akri authenticate with devices with unique credentials and no certificate chain? For example, ONVIF supports doing authentication via username and password. How would the Discovery Handler know which username and password to use for each device? Is the identifier determined by Akri, the protocol, or the secret store infrastructure? Are these user/pass pairs be mounted into the Discovery Handler? For example, say an operator has a set of ONVIF IP cameras on the network. The operator could upload the secrets to a secret store, associating each with a MAC address. Then, when Akri discovers a camera, it will get the proper secret for the camera at that MAC address and authenticate.

The key here is figuring out how to pair each secret with the appropriate device so brute force authentication is not needed. Additionally, these secrets need to be given to the Discovery Handler. Are they mounted in the Pod, hosted locally on a service on the Node, or hosted in the cloud?
## Scenario 3: TPM based Security
TODO

## Future
The following is a list of future work that could enable secure IoT scenarios with Akri.
- Summarize devices on the network that are not expected to be on the network
- Notify when devices go offline and should be fixed
- Can Akri add the concept of time limit to resource usage? This could be an extension to the device plugin framework where a container only gets to use that device for the given amount of time. Then, the broker would needs to be redeployed and reauthenticate to continue use.
- Can Akri restrict what part of a device an app can use? For example. a battery monitoring app doesn’t need access to a camera picturing services. This is similar to `DeviceSpec` in the device plugin API for local devices which limits access to groups and permissions.