Skip to content

Management of Cryptographic Material#

Purpose of this Document#

This document describes what types of cryptographic material are used by the SCL and its individual components, what it is used for, and where it is stored. It depicts the target state and not the current implementation state. How, where, and by whom the cryptographic material is generated and how it is distributed to the components is briefly discussed in the last part of this document.

Cryptographic Material per Component#

In general, TLS is used to ensure authentication and confidentiality between communication partners. Client and server certificates signed by a trusted global root certificate are used for authentication between the components of the SCL. The access to resources is always initiated exclusively from SCL services to infrastructure APIs and not vice versa. This way, a second line of defense from attackers who might break out of the guest VM is present. A compromise of management nodes or the control VMs on these nodes is not considered.

Crypto Material per Component

The cryptographic material required or managed by the components is stored in the RW memory of the component context. The following sections describe for each component individually what kind of cryptographic material is stored and what it is used for.

Identity Management#

The Identity Managament (IDM) system is used to authenticate users to the Infrastructure Management (IM) API. It only stores the hashed user credentials and uses the OpenID standard to provide stateless authentication via signed JSON Web Tokens. The user data can only be modified by the user itself and does not require a process for automatic renewal. The validity of tokens is in accordance with the OpenID specification. Additional access restrictions may be encoded in the tokens.

Cryptographic Material:

  1. Server certificate and private key for TLS access to the IDM itself (for user authentication and possibly administration)
  2. Password hashes to validate user credentials
  3. JSON Web Key SET (JWKS) to sign the JSON Web Tokens (JWTs)

Infrastructure Management#

The Infrastructure Management API controls the user's access to the resources of their separation context. To verify the user's permissions, the signature of the JWT is validated first. This requires the public key of the IDM's JWKS, which can be retrieved from the IDM via TLS secured connection. We are considering pinning either the IDM server certificate or the JWKS public key to further strengthen the authenticity of the transmitted information. If additional rights or access restrictions are encoded in the tokens, these are also taken into account by the IM before the request is forwarded to the SCL API.

Cryptographic Material:

  1. Server certificate and private key for TLS
  2. Client certificate for mTLS authentication towards the SCL API

Separation Control Layer API#

This API allows to create, read, update and remove resources for all separation contexts. Any service that wants to access the SCL API must authenticate itself with a client certificate. In addition, other information encoded in the certificate can be used for fine-grained access control to specific resources, for example, to restrict the access of the storage controller to resources of type volume.

The SCL API acts as gatekeeper toward the persistent state of the etcd database (cluster). Again, mutual authentication is ensured via mTLS with a client certificate.

Cryptographic Material:

  1. Server certificate and private key for TLS
  2. Client certificate for mTLS authentication towards etcd

Generic Controller#

Each controller, regardless of which resource it manages, requires a client certificate to authenticate itself to the SCL API. Whether and which other secrets are managed by the controller depends on its functionality. It can be assumed that further cryptographic material is required for the infrastructure interfaces, such as a key for the Node API, the Storage API or the SmartNIC API. The type of material, whether symmetric or asymmetric, still has to be defined. As already mentioned, it is strongly recommended to run all controllers separately from the guest workloads on the management node. An exception could be the VM controller, which can run on each compute node for scalability reasons.

Cryptographic Material:

  1. Client certificate for mTLS authentication towards the SCL API
  2. (Infrastructure API Key)

Etcd#

Etcd is used as the persistent database system of SCL. It natively provides the use of mTLS via client certificates as well as authentication of peer instances. As of now it is not planned to store any cryptographic material inside it.

If an ETCD cluster is used for load balancing and failover, the individual etcd instances must authenticate each other by providing peer certificates.

Cryptographic Material:

  1. Server certificate and private key for TLS
  2. Peer certificate and private key for server to server TLS

Discussion Points#

Integration with other Components#

As outlined in the architecture document, the SCL Management system integrates with several underlying components, such as the hypervisors and the network. All of these systems are subject to their own security and key management considerations specific to their use case and components. As not all of these modules are defined in detail, yet, it is possible that extensions and/or adaptations to the above described concepts have to be made.

Beside the underlying APIs, some higher-level components access the SCL Management system and perspectively load-balancing plus high availability mechanisms have to be provided in that access path. This needs to be considered with respect to the implemented encryption and authentication mechanisms, though, due to the use of TLS and HTTPS APIs, widely-used and validated solutions exist.

Cluster Management Integration#

To use the Yaook Managed K8s Cluster Management system, no additional key material is needed by the SCL management layer, as all operations after the initial SCVM creation occur in a tenant-specific context. Only the Terraform provider has to be configured with an access token issued by the IDM to get access to the resources of the SC and to create new resources in the same manner as described for normal IaaS management as described above. All other keys leveraged by Yaook K8s are neither managed nor generated by the SCL Management system. These are SSH keys for access to the VMs and a Wireguard key pair for accessing the K8s cluster. These keys are generated by the user and remain on the host.

Lifecycle of Cryptographic Material#

As mentioned at the beginning of this document, one of the most important unresolved issues is the overall lifecycle and rotation of the cryptographic material required for service interaction (the user credentials and tokens are subject to the used IDM implementation and considered out of scope here). Since we have already agreed to use TLS for all component interfaces, a common system-wide solution is preferred. Overall, the lifecycle process can be broadly divided into the following steps, with each step raising specific questions toward the handling of the cryptographic material:

  1. Generation
    • Where are the certificates and keys generated?
    • Where the root certificate (for signing the client and server certificates) is stored and how it is protected?
  2. Distribution
    • How is the crypto material distributed to the components?
  3. Revocation
    • How are certificates revoked?
    • How are the components informed about revoked certificates?
  4. Renewal
    • What's the general life time of the crypto material?
    • How can the crypto material be renewed?

We recommend that a dedicated concept for security lifecycle management is developed by a group with the necessary cryptographic and operational expertise.