[bitnami/*] MAJOR CHANGE: Security defaults

[javsalgar]

We are currently working on improving the overall security in our charts. During the following days, we will publish PRs with the following titles:

[bitnami/APP] feat!: 🔒 💥 Improve security defaults

Changes

These PRs perform the following changes:

Set runAsGroup to 1001

Up until now, Bitnami charts were using user 1001 and group root (following Openshift standards). However, there are Kubernetes platforms that do not allow using group root. With the new changes, containers will no longer need group root to work, becoming 1001 the new default runAsGroup.

This behavior can be reverted by setting runAsGroup back to 0.

The following charts are not affected by this change:

• concourse (worker node): requires root user
• discourse: not compatible with container logic
• fluentd: requires root user
• grafana-loki (promtail): requires root
• grafana-operator (deployed grafana container): not compatible with container logic
• joomla: not compatible with container logic
• kiam: requires root
• magento: not compatible with container logic
• matomo: not compatible with container logic
• metallb: requires root
• moodle: requires root
• multus-rni: requires root
• odoo: requires root

Set readOnlyRootFilesystem to true

Using immutable filesystems is a mandatory requirement in most security checklists (such as NSA or MITRE). To allow this, we needed to change all writable paths of containers to emptyDir volumes. In some cases, we needed to add extra init containers that copy folders like conf, plugins or logs. This is because mounted volumes substitute the contents of the original folders.

IMPACT: This may cause issues with customization scripts like initScripts or using custom command and args. Using older versions of Bitnami containers may cause issues as they may not contain the required bash changes to allow readOnlyRootFilesystem.

This behavior can be reverted by setting readOnlyRootFilesystem back to false.

The following charts are not affected by this change since the container logic is not compatible:

• discourse
• joomla
• magento
• matomo
• moodle
• odoo

Enable resourcePresets by default

Having pods without any resource requests or limits is strongly discouraged. These containers may cause major problems like draining node resources. Currently, our charts warn the user if the resources object is not set. In addition to this, we have the resourcesPreset value to help users test different resource configurations, but this is not recommended for production. In the new changes, we set the resourcesPreset value to the minimum size that works in our internal testing. This is by no means the recommended size by the Bitnami team, but it is the minimum size to perform basic testing of the solution. We insist that users should set their own resource values according to their needs and use case.

IMPACT: Users already setting the resource value should be unaffected by this change. Those that were not setting resources may see a performance drop in their workloads as they would be configured to a minimal value for basic testing. If that is the case, we strongly advise you to set the resources value before performing any upgrade.

This behavior can be reverted by setting resourcesPreset back to none

Perform automatic adaptation of securityContext sections in Openshift

Before this change, Bitnami charts were not working in Openshift restricted-v2 SCC because they were setting user and group to 1001. To fix this, we enabled the automatic adaptation of the containerSecurityContext and podSecurityContext sections when running in Openshift installations. If the detected platform is Openshift, the values runAsUser, runAsGroup and fsGroup will be removed automatically, letting the Openshift platform select the proper user and group IDs.

IMPACT: Users deploying in platforms different from Openshift are unaffected by this change. Openshift users setting their own runAsUser, runAsGroup and fsGroup values will find that these are removed on upgrade.

This behavior can be reverted by setting global.compatibility.openshift.adaptSecurityContext to false.

Other changes previous to this major

In the previous major, we also performed a set of non-breaking changes

Do not use the default serviceAccount

Now charts are generating their service account to avoid using the default in the namespace, which could have unwanted RBAC permissions or image pull credentials.

This behavior can be reverted by setting serviceAccount.create=false

Create NetworkPolicies by default

Charts are creating NetworkPolicy objects with the following default behavior:

• Open egress. This can be changed by setting networkPolicy.allowExternalEgress=false
• Ingress limited to the application containerPorts

This behavior can be reverted by setting networkPolicy.enabled=false

Add liveness/readiness probe to all objects

While this is part of our default behavior since the beginning, some objects were missing the probes section. Now all objects contain liveness and readiness probes.

This behavior can be reverted by setting readinessProbe.enabled=false and livenessProbe.enabled=false

Support Kubernetes PSA restricted

To support the Kubernetes Pod Security Admission restricted, we needed to change the default values for containerSecurityContext, such as 'runAsUser=1001', capabalities.drop=["ALL"], allowPrivilegeEscalation=false, runAsRoot=false, or hostNetwork=false. This has been implemented in all applications that do not require privileges to run. Exceptions include applications like metallb, fluentd, whereabouts or multus-cni.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.