Limitations

Namespaces and the project field

The project field of a CEX config set should match the namespace of the container requesting a member of this set. This results in only blue applications being able to allocate blue APQNs from the blue config set.

Unfortunately, the allocation request that is forwarded from the Kubernetes system to the CEX device plug-in does not provide any namespace information. Therefore, the plug-in is not able to check the namespace affiliation.

When the container runs, the surveillance loop of the CEX device plug-in detects this mismatch and displays a log entry:

PodLister: Container <aaa> in namespace <bbb> uses a CEX resource <ccc> marked for project <ddd>!.

This behavior can be a security risk as this opens the possibility to use the HSM of another group of applications. However, to really exploit this, more is needed. For example, a secure key from the target to attack or the possibility to insert a self made secure key into the target application.

As a workaround, you can set quotas for all namespaces except for the one that is allowed to use the resource. See the following example:

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: cex-blue-quota-no-red
      namespace: blue
    spec:
      hard:
        requests.cex.s390.ibm.com/red: 0
        limits.cex.s390.ibm.com/red: 0

This yaml snippet restricts the namespace blue to allocate zero CEX resources from the crypto config set cex.s390.ibm.com/red. The result is that all containers, which belong to the blue namespace, are not able to allocate red CEX resources anymore.

Sample CEX quota restriction script shows a bash script that produces a yaml file, which establishes these quota restrictions.