Home / Keptn v1 Docs / News / Vulnerability Bulletins / Keptn-Vulnerability-2020-002
|1.0||July 8, 2020||Initial Reason|
Keptn installation 0.6.2 and older.
While implementing Keptn 0.7 significant effort was put into hardening the Keptn installation. This resulted in a more fine-grained approach using dedicated ServiceAccounts for Keptn-services that require access to the Kubernetes API and restricting all other services to a very limited default role that has no access at all.
Installing Keptn 0.6.2 and older required the installation of a ClusterRoleBinding that granted Keptn and all Keptn-services the cluster-admin roles on Kubernetes (see https://github.com/keptn/keptn/blob/0.6.2/installer/manifests/keptn/rbac.yaml ). This role binding gives Keptn-services - pods that are running in the Keptn namespace - full access to the Kubernetes cluster via kubectl and the Kubernetes API. This access was and still is needed in certain cases. For instance, the continuous delivery use-case of Keptn (e.g.,
keptn onboard service &
keptn send new-artifact) will create namespaces in the Kubernetes cluster, edit VirtualServices and apply Helm releases via the Kubernetes API.
CVSSv3.1 Rating: 6.4 (Medium)
CVSSv3.1 Vector: AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L
Please note that this does not imply that Keptn 0.6.2 (and older) are insecure. However, if a vulnerability (either in Keptn-service or any third-party service/component) allows remote code execution or shell access, an attacker could abuse the fact that Keptn-services have cluster-admin roles on the Kubernetes cluster.
We recommend upgrading to Keptn 0.7 as soon as possible. In the meantime, users should take the following actions:
kubectl get deployments -n keptn –owide). It is recommended to review services belonging to keptn-sandbox https://github.com/keptn-sandbox/ or keptn-contrib https://github.com/keptn-contrib/ . If you have any concerns or reasons to distrust a service, please uninstall it by deleting the deployment.
Manually apply the changes to use the service-accounts (e.g., keptn-default, …) for the Keptn core service deployments and all additionally installed Keptn services. Please note that this workaround is not documented in detail.
There is no easy way of detecting whether the vulnerability is or has been abused. We recommend investigating all Kubernetes resources/workloads/pods/deployments/services/… within all namespaces on the Kubernetes cluster.