In the previous post of this little series we talked about preventing spoofing on Kubernetes. Today we’ll talk about the T of STRIDE: Tampering.
Tampering is the act of changing something in a malicious way, to gain extra privileges or for denial of service.
Generally for preventing tampering is important to:
- limit the access to critical components;
- control the access to critical components;
Furthermore, it’s important to watch for evidence of tampering.
Generally, a common solution to highlight instances of tampering could be using seals, but let’s apply these concepts to the Kubernetes world.
To protect data in transit, TLS guarantees privacy besides integrity. The communication from the cluster to the API Server is TLS-encrypted (see here to secure traffic to the API Server).
From the developer perspective - even if the line is not so clear - set containers root filesystem to read-only using SecurityContexts, at container or pod level, since the data that needs to be written is usually persisted through volumes:
apiVersion: v1 kind: Pod metadata: name: my-secure-pod spec: containers: # ... securityContext: readOnlyRootFilesystem: true # ...
From the administrator perspective, the best defense against data tampering is to validate data before processing it. For example the vulnerability CVE-2019–11253 was found last year and this is the related issue on GitHub, there are also described recommended mitigation actions.
- creating Pods with non read only root filesystems:
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: my-psp-ro-rootfs # ... spec: # ... readOnlyRootFilesystem: false # ...
- creating Pods that access host filesystem to not allowed paths through hostPath volumes, by specifying a whitelist of host paths that are allowed to be used by hostPath volumes:
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: my-psp-hostpaths # ... spec: # ... allowedHostPaths: - pathPrefix: "/example" readOnly: true # ...
Important: Remember to authorize the policies before enabling the Pod Security Policy admission controller, otherwise it will prevent any pods from being created in the cluster. See here to know how to do it.
Restrict access to the container images' registry. For example, on AWS you can enforce IAM policies on ECR repositories.
Restrict access to the repositories of the configuration files. It can be obvious but do not store sensitive data on repositories, instead use Secrets. Moreover, evaluate if you need a secrets manager such as Vault; you can use it to inject Secrets through sidecars.
It can be installed standalone or as a DaemonSet; follow this guide to know how to install and use it.
Watch for evidence of tampering
Verify downloaded binaries for the container runtime by running SHA-2 checksum. For the purpose of the conciseness of this post I don’t talk about it here, but you can read this simple howto.
That’s all for this part, thank you and stay tuned for the next one.