Kubernetes Secrets of Fortune 500 Companies Exposed in Public Repositories
Cybersecurity researchers are warning of publicly exposed Kubernetes configuration secrets that could put organizations at risk of supply chain attacks.
“These encoded Kubernetes configuration secrets were uploaded to public repositories,” Aqua security researchers Yakir Kadkoda and Assaf Morag said in a new research published earlier this week.
Some of those impacted include two top blockchain companies and various other fortune-500 companies, according to the cloud security firm, which leveraged the GitHub API to fetch all entries containing .dockerconfigjson and .dockercfg, which store credentials for accessing a container image registry.
Of the 438 records that potentially held valid credentials for registries, 203 records – about 46% – contained valid credentials that provided access to the respective registries. Ninety-three of the passwords were manually set by individuals, as opposed to the 345 that were computer-generated.
“In the majority of cases, these credentials allowed for both pulling and pushing privileges,” the researchers noted. “Moreover, we often discovered private container images within most of these registries.”
Furthermore, nearly 50% of the 93 passwords were deemed weak. This comprised password, test123456, windows12, ChangeMe, and dockerhub, among others.
“This underscores the critical need for organizational password policies that enforce strict password creation rules to prevent the use of such vulnerable passwords,” the researchers added.
Aqua said it also found instances where organizations fail to remove secrets from the files that are committed to public repositories on GitHub, leading to inadvertent exposure.
But on a positive note, all the credentials associated with AWS and Google Container Registry (GCR) were found to be temporary and expired, making access impossible. In a similar vein, the GitHub Container Registry required two-factor authentication (2FA) as an added layer against unauthorized access.
“In some cases, the keys were encrypted and thus there was nothing to do with the key,” the researchers said. “In some cases, while the key was valid it had minimal privileges, often just to pull or download a specific artifact or image.”
According to Red Hat’s State of Kubernetes Security Report released earlier this year, vulnerabilities and misconfigurations emerged as top security concerns with container environments, with 37% of the total 600 respondents identifying revenue/customer loss as a result of a container and Kubernetes security incident.