# Quantum Key Distribution in Kubernetes Clusters
## 4 Integration in a Kubernetes Cluster
### Resource Creation and Key Exchange  
In this section, we analyse the details of the resource creation and the overall logic behind PTP and MH exchanges. There are some assumptions behind the possibility of registering SAEs and performing key requests. First, we need to have a QKD network and two or more Kubernetes clusters, as depicted in Figure 3. Second, at least one QKDM has to be deployed on each cluster as well as the QKS deployment. Third, we need to install and configure the QSS operator on each cluster to work with the Kubernetes API instead of the QKS interface. The last assumption is that there is a continuous exchange among the QKDMs involved, and so all the registration processes and the KS creation have been handled as described in Sections 2.3 and 3. Regardless of the type of exchange (PTP or MH), we need all the SAEs involved registered within the network. This operation is feasible according to the workflow depicted in Figure 6. An SAE admin, who is in charge of managing the SAE resource in Kubernetes and requiring QKD keys, can create a Sae resource. A custom operator can also handle this action without human intervention. After the resource creation, the QSS operator recognises the new Sae resource and starts the registration of this resource to Keycloak. Again we have two options: register the SAE to Keycloak in advance (manual registration) or let the QSS operator handle this part (automatic registration). This choice can be selected in the descriptor in Figure 4. Once an SAE can be authenticated through Keycloak, the QSS Operator registers it to the QKS, and if the automatic registration process is enabled, it retrieves the credentials to access the QKS by creating a specific Kubernetes secret. Notice that since the scope of the operator is global within the cluster, an SAE could be in a namespace different from the QKS one.  
Once two registered SAEs want to exchange a key, a resource of type KeyRequest needs to be created. In particular, the SAE admin/operator again is in charge of applying  
Figure 5: KeyRequest resource YAML descriptor.  
Figure 6: SAE registration process. SAE admin/operator creates a resource of type Sae (1). QSS operator monitors resource creation (2). When it finds the new Sae it starts the registration to Keycloak (3) and the QKS core (4). At the end of the process it retrieves the SAE credentials (5).  
the resource (Figure 5), specifying as parameters the key length, the number of keys required, mSAE, and sSAE. The workflow (depicted in Figure 7) is similar to the previous case of SAE registration: the QSS operator detects the creation of the KeyRequest resource, authenticates the SAE through Keycloak, requests the key material to the QKS, which starts the KRP and retrieves the key material to the QSS operator, and stores the final keys as a Kubernetes secret.  
Looking at Figure 3, it is worth mentioning that, given an SAE within Cluster 1 as the initiator (or mSAE) of the request, the responder SAE (or sSAE) within Cluster 2 has to perform another KeyRequest indicating the IDs of the keys that it wants to retrieve. That information could be exchanged on an authenticated channel, and also this process could be automated using a custom operator in Kubernetes. After this second request, all the SAEs involved have access to a Kubernetes secret representing the key material generated through the QKD.  
The operator also supports MH exchanges, whose scheme is similar to the one depicted in Figure 1 where it is mentioned the possibility to exchange keys between Node A and Node C, using Node B as a Trusted Repeater. This is compliant with what we presented in Section 3.2; thus, given a QKD network where clusters are the nodes, we still can perform exchanges traversing those clusters and leveraging QSS operators.