CVE alerts for
Kubernetes

A privilege-escalation issue in the Portworx Operator when deployed on Red Hat OpenShift (OCP). Only under specific conditions during the initial provisioning of a Portworx storage cluster, a user holding only limited, namespace-scoped permissions could cause the operator to grant broader access than intended, potentially resulting in elevated privileges within the Kubernetes cluster.

The source-controller is a Kubernetes operator, specialised in artifacts acquisition from external sources such as Git, OCI, Helm repositories and S3-compatible buckets. In versions 0.0.17 through 1.8.4, an actor with the ability to influence the contents of a bucket referenced by a `Bucket` resource can cause source-controller to write fetched object data to paths outside the per-reconciliation working directory. The corruption surface is bounded by source-controller's own and downstream Flux controllers' digest verification: source-controller verifies stored artifact digests during reconciliation and rebuilds on divergence; consumers (kustomize-controller, helm-controller) verify the digest of fetched artifacts and reject mismatches. These checks prevent a manipulated artifact from reaching the cluster, but an attacker can still write files anywhere the source-controller pod has permission to write. Separately, a user with permission to create or update `GitRepository` resources can cause source-controller to test for the existence of paths outside the cloned repository. Because the result is exposed via the resource's status, this allows limited enumeration of file paths on the controller pod. This surface exists only on source-controller v1.6.0 and later, where the sparse-checkout feature was introduced. This vulnerability was fixed in source-controller v1.8.5. There is no in-product workaround. Users should upgrade to a patched version. As a defense-in-depth measure for the GitRepository sparse-checkout surface, a `ValidatingAdmissionPolicy` (or a third-party policy engine such as Kyverno or OPA Gatekeeper) can be deployed to reject `GitRepository` resources whose `.spec.sparseCheckout` entries contain `..` or absolute path segments.

In the current development version of Eclipse aeriOS, for which no official release has yet been published, the Identity Manager (IdM) deployment included insecure default configurations and credentials for security-sensitive services. The Helm chart exposed the Keycloak service and its PostgreSQL backing database through Kubernetes NodePort services by default, while the Docker Compose deployment similarly exposed PostgreSQL on all network interfaces. The deployment included fixed default credentials for the Keycloak administrator and PostgreSQL database user, and the previous Helm chart configuration did not provide adequate secret management for these credentials. In addition, predefined application users with known credentials were provided for development and testing without sufficiently warning operators against their use in production environments. An attacker able to reach the exposed services could use the published default credentials to obtain administrative access to the Identity Manager or direct access to its database. This could allow unauthorized access to or modification of identity-management data, including users, roles, client credentials, sessions, and cryptographic material, and could enable the creation of privileged identities or tokens accepted by other aeriOS components. The issue has been addressed by generating a random Keycloak administrator password by default, managing Keycloak and PostgreSQL credentials through Kubernetes Secrets, and restricting PostgreSQL to an internal service in both the Helm chart and Docker Compose deployment. OpenLDAP is also restricted to an internal service. The predefined users intended for development and testing are retained, but the documentation now explicitly warns that their default credentials must not be used in production and that these users should be removed or their credentials changed after installation.