Aiven’s Kubernetes operator for managing cloud services contains a serious flaw: developers with permission to create ClickHouseUser custom resources in their own namespace can steal secrets from any other namespace in the cluster. A single kubectl apply command lets them pull production database credentials, API keys, or service tokens. The operator, acting as a confused deputy, reads the target secret using its cluster-wide permissions and copies sensitive data into the attacker’s namespace.
This vulnerability, tracked as a security advisory from Aiven, stems from the operator’s ServiceAccount possessing broad read/write access to secrets across the entire cluster via the aiven-operator-role ClusterRole. When processing a ClickHouseUser resource, the operator trusts the user-supplied spec.connInfoSecretSource.namespace field without validation. It fetches the secret from that namespace—regardless of boundaries—and extracts the password to create a new secret in the attacker’s space.
Why This Breaks Kubernetes Security Assumptions
Kubernetes namespaces provide logical isolation in shared clusters, especially in multi-tenant environments like dev/test/prod setups or managed services. RBAC typically limits users to their own namespace, but operators often require elevated privileges to manage resources. Here, the Aiven operator’s ClusterRole grants get, list, and create on secrets cluster-wide. No admission webhook blocks cross-namespace references: the ServiceUser webhook returns nil, and no specific ClickHouseUser validation exists.
Attackers need only create permissions on ClickHouseUser CRDs in their namespace—common for devs working with Aiven’s ClickHouse service. They craft a malicious YAML like this:
apiVersion: aiven.io/v1alpha1
kind: ClickhouseUser
metadata:
name: exploit-user
namespace: attacker-ns
spec:
project: myproject
serviceName: clickhouse-prod
connInfoSecretSource:
name: victim-secret
namespace: production-ns # Arbitrary victim namespace
# ... other fields
The operator reconciles it, reads victim-secret from production-ns, and writes the password to attacker-ns. Boom—secrets exfiltrated. In a real cluster, this enables lateral movement: a compromised dev account steals prod DB creds, escalates to full compromise.
Scope and Real-World Risk
Aiven operators versions before 0.37.0 expose clusters running ClickHouse services. Aiven manages open-source databases like ClickHouse on clouds such as AWS, GCP, and Azure, handling petabyte-scale analytics workloads for companies in finance, gaming, and e-commerce. Thousands of deployments likely run vulnerable operators, per public GitHub stats and adoption metrics from CNCF landscapes.
This isn’t isolated. Kubernetes operators frequently suffer confused deputy issues—recall FluxCD’s image policy vulns or cert-manager’s secret leaks. A 2023 CNCF security report flagged operator privilege escalation in 40% of audited projects. Aiven’s case underscores the risk: service meshes and DBaaS operators wield god-like perms by design, but poor input validation turns them into backdoors.
Why it matters: In gitops pipelines or CI/CD, devs apply CRDs routinely. A single PR or insider threat weaponizes this. Multi-tenant K8s (e.g., AWS EKS, GKE) amplifies blast radius—tenants steal from each other. Quantify the damage: leaked ClickHouse creds grant query access to sensitive data lakes, costing millions in breaches per Verizon’s DBIR.
Aiven patched it in version 0.37.0 by adding namespace validation, likely restricting connInfoSecretSource.namespace to the CRD’s own namespace. They credit Andrés Cruciani via their Bugcrowd bounty program, paying out responsibly. Fair play—Aiven disclosed promptly, no evidence of exploits in the wild yet.
Fixes, Workarounds, and Hardening Steps
Upgrade to 0.37.0 immediately: helm upgrade aiven-operator aiven/aiven-operator --version 0.37.0 or equivalent. Audit clusters with:
$ kubectl get clickhouseuser --all-namespaces -o yaml | grep connInfoSecretSource.namespace
Check for suspicious cross-ns refs. Revoke unnecessary CRD creates via RBAC: limit to create in own ns only.
Broader lessons: Use tools like Kyverno or OPA Gatekeeper for cross-ns policies. Kyverno can deny CRDs with spec.connInfoSecretSource.namespace != metadata.namespace. Audit operator ClusterRoles—principle of least privilege applies. Tools like kubeaudit or Trivy scan for overperms.
Skeptically, patches fix symptoms, but operator trust models remain fragile. Run operators in separate namespaces with NetworkPolicies. For high-sec, airgap or self-host without cloud operators. This vuln reminds: Kubernetes security is RBAC plus validation everywhere. Aiven users, act now—your prod secrets hang in the balance.
