Add Confidential Container Support for 5G Core Network Functions #76
Conversation
Signed-off-by: Marcin Spoczynski <[email protected]>
gab-arrobo
requested review from
Copilot,
gab-arrobo,
ghislainbourgeois and
thakurajayL
|
@sandlbn, please resolve the conflict. Thanks! |
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for confidential containers for 5G core network functions using Kata Containers. Key changes include:
- Introducing configurable runtime classes, pod annotations, and an attestation init container.
- Extending values.yaml with a new confidential container configuration section.
- Updating deployment templates and helper templates to embed the new confidential container behavior.
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| 5g-control-plane/values.yaml | Adds configuration for confidential container and attestation info |
| templates/deployment-*.yaml | Updates deployment templates (AMF, SMF, NRF, PCF) to conditionally apply runtime settings and annotations |
| templates/_helpers.tpl | Introduces helper templates for confidential container annotations and attestation init container |
| helm.sh/hook-weight: "5" | ||
| {{- toYaml . | nindent 8 }} | ||
| {{- end }} | ||
| {{- if .Values.confidentialContainers.enabled }} |
There was a problem hiding this comment.
Consider aligning the annotation condition here with the other deployment templates by checking 'or .Values.confidentialContainers.enabled .Values.confidentialContainers.annotation.enabled' to ensure consistent handling of confidential container annotations.
| {{- if .Values.confidentialContainers.enabled }} | |
| {{- if or .Values.confidentialContainers.enabled .Values.confidentialContainers.annotation.enabled }} |
| */}} | ||
| {{- define "5g-control-plane.confidential_annotations" -}} | ||
| {{- if or .Values.confidentialContainers.enabled .Values.confidentialContainers.annotation.enabled }} | ||
| io.containerd.cri.runtime-handler: kata-qemu |
There was a problem hiding this comment.
To improve maintainability, consider using the runtimeClassName defined in the configuration (e.g., .Values.confidentialContainers.runtimeClassName) instead of hardcoding 'kata-qemu'.
| io.containerd.cri.runtime-handler: kata-qemu | |
| io.containerd.cri.runtime-handler: {{ .Values.confidentialContainers.runtimeClassName | default "kata-qemu" }} |
| sleep 5; | ||
| elapsed=$((elapsed + 5)); |
There was a problem hiding this comment.
[nitpick] Consider parameterizing the retry sleep interval (currently hardcoded as 5 seconds) to allow tuning of the attestation check frequency based on deployment needs.
| sleep 5; | |
| elapsed=$((elapsed + 5)); | |
| sleep {{ .Values.confidentialContainers.attestation.retryInterval | default 5 }}; | |
| elapsed=$((elapsed + {{ .Values.confidentialContainers.attestation.retryInterval | default 5 }})); |
| repository: "" #default docker hub | ||
| tags: | ||
| init: omecproject/pod-init:rel-1.1.2 | ||
| attestation: storytel/alpine-bash-curl:latest |
There was a problem hiding this comment.
I think we should find a better image for this, it seems unmaintained, and the organization is unknown to me.
3 participants
This PR adds support for deploying 5G core network functions in confidential containers using Kata Containers runtime.
Changes:
Added configurable runtime class support for all core NFs (AMF, SMF, NRF, UDR, UDM, AUSF, PCF, NSSF)
Added optional attestation init container with configurable timeout
Added Kata-specific pod annotations with customizable kernel parameters
Updated _helpers.tpl with reusable templates for confidential container configuration
Added new configuration section in values.yaml with flexible enable/disable options
Tested with Kata Containers kata-qemu runtime
Confirmed backward compatibility with existing deployments