Description
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.
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.
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.