T09 · Insecure Skill Coding Practices
- Location
KEDA-TRIGGERS.md:39- Finding
Plaintext RabbitMQ Credentials Embedded in Trigger Configuration
- Content
View full analysis
Vulnerability Details
File Location:
KEDA-TRIGGERS.md, lines 31–40; the vulnerable credential-bearing URI is on line 39.
Vulnerability Type: Plaintext credentials in configuration
Risk Level: MediumComplete Code Snippet:
yaml triggers: - type: rabbitmq metadata: protocol: amqp queueName: my-queue mode: QueueLength value: "10" host: amqp://user:pass@rabbitmq.default.svc:5672Technical Analysis
The RabbitMQ example places a username and password directly inside the AMQP connection URI. Although
user:passappears to be illustrative rather than a real credential, the example promotes an insecure deployment pattern that users may copy and replace with production credentials.KEDA trigger metadata is stored in Kubernetes resources and can be exposed through source repositories, GitOps history, manifest archives, CI/CD logs, Kubernetes API queries, diagnostic output, and administrative tooling. Embedding credentials in a URI may also cause them to appear in error messages or logs produced while validating or connecting to RabbitMQ.
Sensitive authentication material should instead be held in a Kubernetes Secret and accessed through a KEDA
TriggerAuthenticationresource. Access to that Secret should be constrained through namespace isolation and least-privilege RBAC.Attack Path
- An operator copies the documented RabbitMQ trigger example into a deployment manifest.
- The placeholder username and password are replaced with valid RabbitMQ credentials while preserving the inline URI pattern.
- The manifest is committed to source control, processed by a CI/CD pipeline, or submitted to the Kubernetes API.
- An attacker with read access to the repository, pipeline output, manifest history, Kubernetes resource, or relevant diagnostic logs extracts the connection URI.
- The attacker connects to the reachable RabbitMQ service using the disclosed credentials ...[truncated 945 chars]
- Remediation
View remediation
Remediation Suggestions
-
Remove credentials from the RabbitMQ connection URI in trigger metadata.
-
Store the RabbitMQ connection string or individual authentication values in a Kubernetes Secret.
-
Define a KEDA
TriggerAuthenticationresource that references the Secret and attach it to the RabbitMQ trigger withauthenticationRef. -
Update the documentation with a secure example, such as:
yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-credentials type: Opaque stringData: host: amqp://user:replace-with-secure-password@rabbitmq.default.svc:5672 --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: rabbitmq-auth spec: secretTargetRef: - parameter: host name: rabbitmq-credentials key: host --- triggers: - type: rabbitmq metadata: protocol: amqp queueName: my-queue mode: QueueLength value: "10" authenticationRef: name: rabbitmq-auth -
In production, create the Secret through an external secret manager or a protected deployment mechanism rather than committing the populated Secret manifest to source control.
-
Apply least-privilege RabbitMQ permissions and Kubernetes RBAC so the KEDA operator and authorized workloads are the only principals able to access the secret.
-
Rotate any real credentials that may already have been deployed or committed using the documented inline pattern, and remove them from repository and CI/CD history where feasible.
-