Create standalone CRIDGE Helm chart

changed milestone to %2024Q4-rc

added statusin progress typeenhancement labels

assigned to @dimit.giannopoulos

added to epic &22 (closed)

I write this note in this issue. However we need to consider this for all our HELM packages, OSL etc

Clusters for enhanced security, might enforce the "restricted" PodSecurity standard, which imposes restrictions on pod configurations such as the use of capabilities, security contexts, and seccomp profiles.

When installing CRIDGE via HELM for example we get the error: Error creating: pods "cridge-xxxx-qvgcb" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "cridge-remote-cr77935ae9-cridge" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "cridge-remote-cr77935ae9-cridge" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "cridge-rxxx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "cridge-rxxx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

the rest are notes generated from chatgpt:

To resolve this, you need to modify the Helm chart to comply with the security policies by adjusting the pod security settings. Here’s how you can resolve this issue by updating the securityContext settings. Key Problems in the Error:

Unrestricted Capabilities:
The containers (xxxxx) must explicitly drop all capabilities (capabilities.drop=["ALL"]).

Seccomp Profile:
The containers must set the seccompProfile to either "RuntimeDefault" or "Localhost".

Steps to Fix the Issue Step 1: Modify the Helm Chart Values for securityContext

In your Helm chart, you need to set the appropriate security context for the containers. Depending on how the chart is structured, you can usually modify the values.yaml file or directly within the pod/container template.

Step 2: Apply the securityContext to All Affected Containers if any

We will also need to include the option of providing the kubeconf as base64

mentioned in merge request !9 (merged)

marked this issue as blocking osl/documentation#10 (closed)

@ktrantzas, @tranoris

While we can implement some of the required security context features to enhance security, there are limitations due to how the images are currently built.

Security Context Fields That Can Be Set

• allowPrivilegeEscalation: false
• capabilities.drop: ["ALL"]
• seccompProfile.type: "RuntimeDefault"

These settings can be applied without issues.

Security Context Fields That Cannot Be Set

• runAsNonRoot: true
• runAsUser: 1000

The following restriction prevents us from enforcing the above fields:

Error: container has runAsNonRoot and image will run as root

This error indicates that the container's base image is configured to run as the root user, which conflicts with the runAsNonRoot setting. This suggests that certain functionalities within the container require root permissions to operate.

During testing, the following error was observed in the pod logs:

java
JVMSHRC155E Error copying username into cache name
JVMJ9VM015W Initialization error for library j9shr29(11): JVMJ9VM009E J9VMDllMain failed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

This error is related to the JVM's shared class cache and may be a consequence of the security restrictions or lack of necessary permissions for the JVM to initialize properly.

mentioned in issue osl/documentation#10 (closed)

mentioned in issue org.etsi.osl.main#37 (closed)

closed