Keptn-Vulnerability-2020-002

Version 1.0

Revision Information

Affected

Keptn installation 0.6.2 and older.

Description

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.

Severity

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.

Recommendations

We recommend upgrading to Keptn 0.7 as soon as possible. In the meantime, users should take the following actions:

• Ensure that Keptn API and Keptn Bridge are not accessible via a public IP. If they are, firewall rules should be put in place to restrict access as much as possible to a limited set of IP addresses.
• Check for third-party services (by executing for example: 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.

Workaround

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.

How to identify whether vulnerability is abused

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.