Security Bulletins

Security Bulletins

From time to time, we might release security bulletins related to ProjectCalico. All security bulletins for ProjectCalico are described here.

Description Severity Notes

Tigera Technical Advisory TTA-2019-001

Title: Fixes available for CVE-2019-9946
Date published: 2019-March-28

Medium N/A

Summary

A vulnerability has been discovered in the “portmap” CNI plugin affecting versions prior to 0.7.5 of the portmap plugin. Portmap is a kubernetes component but is bundled in Tigera Calico & Tigera Secure releases. We also recommend you update to a patched version of Kubernetes to ensure the vulnerable plugin is not in use.

Prior to the fix, HostPort rules would take precedence over more specific services like NodePorts, potentially delivering traffic to the wrong location.

Affected Releases

  • All Tigera Secure Enterprise Edition releases up to and including the following patch releases in their respective minor release streams: v2.3.0, v2.2.3, v2.1.1.
  • All Calico releases up to and including the following patch releases in their respective minor release streams: v3.2.6, v3.3.5, v3.4.3, v3.5.3, v3.6.0.
  • All Calico releases in release streams v3.1.x and earlier

Tigera Secure Cloud Edition is not directly affected, but operators are strongly cautioned to consider whether their Kubernetes platform is affected and update to a fixed version of Kubernetes.

Indicators of Impact/Compromise

Audit your Kubernetes cluster for any pods with hostPorts that conflict numerically with any nodePorts. Conflicts indicate that some traffic may be being misdirected.

Workaround / Remediation

We recommend that all users upgrade to a fixed version of Tigera Calico/Tigera Secure and a fixed version of Kubernetes.

If you cannot update to a fixed version, you can manually install a fixed portmap binary on each Kubernetes node. You will also need to configure Tigera Calico/Tigera Secure not to install the portmap binary by setting the environment variable SKIP_CNI_BINARIES=”portmap” on the install-cni container.

If neither upgrading nor manually installing a fixed portmap binary is possible, you can proactively audit your Kubernetes cluster to ensure that pods are not being created with hostPorts that numerically conflict with nodePorts, and immediately remediate any pod hostPorts that conflict.

Fixed Software

This issue has been fixed in the following patches:

Tigera Software

  • Calico v3.2.7
  • Calico v3.3.6
  • Calico v3.4.4
  • Calico v3.5.4
  • Calico v3.6.1
  • Tigera Secure Enterprise Edition 2.3.1

Kubernetes Software

  • 1.11.9
  • 1.12.7
  • 1.13.5
  • 1.14.0

External Reference

https://discuss.kubernetes.io/t/announce-security-release-of-kubernetes-affecting-certain-network-configurations-with-cni-releases-1-11-9-1-12-7-1-13-5-and-1-14-0-cve-2019-9946/5713

 

Description Severity Notes

Tigera Technical Advisory TTA-2018-001

Title: Calico CNI Logging can expose Kubernetes service account tokens
Date published: 2018-Nov-13

Medium N/A

Summary

In certain scenarios, Calico will write configuration data in log files including service account tokens included in the configuration. This will expose client service account tokens in the log files which could lead to unauthorized cluster access or privilege escalation if users are able to access these log files. This advisory is referenced under Google Security Bulletins on November 13, 2018.

Affected Releases

  • All Calico releases
    • Use of Calico on orchestrators other than Kubernetes (e.g. DC/OS) are not affected
  • Tigera Secure Cloud Edition 1.0
  • Tigera Secure Enterprise Edition 2.2, 2.1

Indicators of Impact/Compromise

Check your CNI configuration file; if the field “k8s_auth_token” has been set (which it is not by default in standard Calico manifests), then that token could have been written as an info level log. Otherwise, the exposure is limited to debug level logs. You can check if any service account tokens have been exposed by searching for the following log lines in the kubelet logs:

  • “Updated stdin data”
  • “Kubernetes config”
  • “Configured environment”
  • “Building client for config”
  • “Config overrides”

An example using journalctl:

journalctl -u kubelet --no-pager | grep "Updated stdin data"

You can check if any service account tokens have been exposed in the calico/node logs by searching for the following log lines in the calico/node logs, for example:

kubectl logs -n kube-system -l k8s-app=calico-node -c calico-node | grep "Building client for config"
kubectl logs -n kube-system -l k8s-app=calico-node -c calico-node | grep "Config overrides"

If any of the above queries contain a Kubernetes service account token, then the cluster is affected by this vulnerability.

Audit all token usage and confirm that there is no unauthorized use of client tokens in your cluster.

Service Account Tokens generated by Kubernetes are valid so long as the token secret exists in Kubernetes. Regenerate tokens to ensure any leaked tokens no longer pose a threat.

Workaround / Remediation

The following workaround steps should be taken if you are running a version of Calico that includes this vulnerability.

  1. Turn off debug logging in Calico. In the kube-system namespace:
    1. Modify the calico-config ConfigMap to set log_level to “warning” or higher.
      kubectl edit configmap -n kube-system calico-config
    2. Modify the calico-node container in the calico-node daemonset to have environment variable FELIX_LOGSEVERITYSCREEN set to “info” or higher.
      kubectl patch ds -n kube-system calico-node --patch \ '{"spec": {"template": {"spec": {"containers": [{"name": "calico-node", "env": [{"name": "FELIX_LOGSEVERITYSCREEN", "value": "warning"}]}]}}}}’
  2. Delete the calico-node service account secret. In the kube-system namespace:
    1. Find the correct secret:
      kubectl get secrets -n kube-system | grep calico-node
    2. Delete the secret:
      kubectl delete secret -n kube-system <SECRET NAME>
    3. A new secret will be automatically generated by the token controller.
  3. Restart all calico-node pods in the kube-system namespace to pick up the new configuration.

After upgrading to a fixed version of the software, you can reset logging to whichever level you prefer.

Fixed Software

This issue has been fixed in the following patches:

  • Calico v3.3.1
  • Calico v3.2.4
  • Calico v3.1.4
  • Calico v3.0.9
  • Calico v2.6.12
  • Tigera Secure CE v1.0.1
  • Tigera Secure EE v2.2.1

If you upgrade from an earlier version to a fixed version, if you have not already done so, you should follow steps (2) and (3) under “Workaround / Remediation” above to ensure any leaked secret is no longer valid.