Summary
In the aas-basyx-v2-full Helm chart, enabling the bundled Keycloak can place the basyx-technical-user client secret in a ConfigMap as well as a Kubernetes Secret. A principal who can read that ConfigMap may use the secret to obtain an admin-role token, potentially gaining broad access to BaSyx repositories and registries.
In the aas-basyx-v2-full Helm chart, enabling the bundled Keycloak can place the basyx-technical-user client secret in a ConfigMap as well as a Kubernetes Secret. A principal who can read that ConfigMap may use the secret to obtain an admin-role token, potentially gaining broad access to BaSyx repositories and registries.
Affected context
The issue affects version 2.2.0 of the Eclipse BaSyx aas-basyx-v2-full chart when the bundled Keycloak is enabled. Its realm-import JSON template substitutes the technical-user client secret into a ConfigMap, even though the chart also stores the secret in a Kubernetes Secret. The bundled Keycloak is disabled by default, and the described exposure depends on the chart configuration and access controls in the release namespace.
The issue affects version 2.2.0 of the Eclipse BaSyx aas-basyx-v2-full chart when the bundled Keycloak is enabled. Its realm-import JSON template substitutes the technical-user client secret into a ConfigMap, even though the chart also stores the secret in a Kubernetes Secret. The bundled Keycloak is disabled by default, and the described exposure depends on the chart configuration and access controls in the release namespace.
Exploit preconditions
- Attack surface: The Keycloak realm-import ConfigMap in the chart's release namespace, plus the Keycloak token endpoint.
- Required access: Permission to read ConfigMaps in the namespace; access to Secrets is not required to obtain the exposed value.
- Trigger point: Reading the ConfigMap and using the client-credentials grant at the Keycloak token endpoint.
- Why exploitation is possible: The realm-import JSON contains the client secret in cleartext, and the client service account has the realm
adminrole. The endpoint must be reachable to exchange the secret for a token.
- Attack surface: The Keycloak realm-import ConfigMap in the chart's release namespace, plus the Keycloak token endpoint.
- Required access: Permission to read ConfigMaps in the namespace; access to Secrets is not required to obtain the exposed value.
- Trigger point: Reading the ConfigMap and using the client-credentials grant at the Keycloak token endpoint.
- Why exploitation is possible: The realm-import JSON contains the client secret in cleartext, and the client service account has the realm
adminrole. The endpoint must be reachable to exchange the secret for a token.
Why this happens
The chart duplicates a sensitive credential into a Kubernetes ConfigMap while rendering the Keycloak realm-import JSON. ConfigMaps are not intended to provide the confidentiality protections associated with Secrets, so principals granted ConfigMap read access may see the credential. This is primarily CWE-312: Cleartext Storage of Sensitive Information; the exposed credential's protection and handling also relate to CWE-522: Insufficiently Protected Credentials.
The chart duplicates a sensitive credential into a Kubernetes ConfigMap while rendering the Keycloak realm-import JSON. ConfigMaps are not intended to provide the confidentiality protections associated with Secrets, so principals granted ConfigMap read access may see the credential. This is primarily CWE-312: Cleartext Storage of Sensitive Information; the exposed credential's protection and handling also relate to CWE-522: Insufficiently Protected Credentials.
Potential impact
- A reader of the ConfigMap could obtain an access token for the technical user.
- The token may grant admin-level access to BaSyx repositories and registries.
- An attacker could create, read, update, or delete repository and registry data.
- An attacker could invoke operations available to the technical user, including execution-capable operations.
- A reader of the ConfigMap could obtain an access token for the technical user.
- The token may grant admin-level access to BaSyx repositories and registries.
- An attacker could create, read, update, or delete repository and registry data.
- An attacker could invoke operations available to the technical user, including execution-capable operations.
General mitigation guidance
Mitigation generally focuses on avoiding the exposure of credentials in broadly readable configuration resources and limiting the authority of credentials that must be used by services.
- Keep client secrets out of ConfigMaps and other resources that may be readable by a wider set of principals.
- Use secure secret references or other mechanisms that avoid rendering secret values into realm-import configuration.
- Limit client roles and permissions to the minimum required rather than granting broad administrative access.
- Restrict ConfigMap read access and access to the Keycloak token endpoint according to operational need.
- Where the affected deployment is in use, consider the vendor-described alternatives of migrating to the
basyxchart or deploying without bundled Keycloak, and rotate the exposed client secret.
Mitigation generally focuses on avoiding the exposure of credentials in broadly readable configuration resources and limiting the authority of credentials that must be used by services.
- Keep client secrets out of ConfigMaps and other resources that may be readable by a wider set of principals.
- Use secure secret references or other mechanisms that avoid rendering secret values into realm-import configuration.
- Limit client roles and permissions to the minimum required rather than granting broad administrative access.
- Restrict ConfigMap read access and access to the Keycloak token endpoint according to operational need.
- Where the affected deployment is in use, consider the vendor-described alternatives of migrating to the
basyxchart or deploying without bundled Keycloak, and rotate the exposed client secret.
How teams detect issues like this
- Review rendered Helm manifests and deployed ConfigMaps for credential values or secret-template substitutions.
- Use static analysis and code review to identify templates that interpolate secret values into ConfigMaps or other non-secret resources.
- Check Kubernetes RBAC policies for principals that can read ConfigMaps in the release namespace, including broad built-in roles.
- Apply deployment policies that prevent sensitive values from appearing in ConfigMaps and flag overly privileged service accounts.
- Review Keycloak client roles and audit token issuance and use for the technical user.
- Review rendered Helm manifests and deployed ConfigMaps for credential values or secret-template substitutions.
- Use static analysis and code review to identify templates that interpolate secret values into ConfigMaps or other non-secret resources.
- Check Kubernetes RBAC policies for principals that can read ConfigMaps in the release namespace, including broad built-in roles.
- Apply deployment policies that prevent sensitive values from appearing in ConfigMaps and flag overly privileged service accounts.
- Review Keycloak client roles and audit token issuance and use for the technical user.
