Page 87 - GiGW3

5. Guidelines

(h) Use an orchestration platform – These systems usually provide secure API endpoints as well
as role-based access control (RBAC), which can help minimise the risk of unauthorised access.
(i) Use immutable deployments – This involves creating an instance image during the build steps.

The deployment can then use this image to create new instances. To update the application, new
images should be created, spin up new instances and then destroy the old ones.
(j) Create separate virtual networks for the containers – This introduces a level of isolation that
can reduce the attack surface.
(k) Apply the principle of least privilege – Allow connectivity only between containers that truly

need it.
(l) Expose only the ports that serve the application – Do not expose any other ports, except for
SSH. Apply this principle to containers as well as the underlying machines.

(m) Use TLS to secure communication between services – This process encrypts traffic and
ensures only authorised endpoints are allowed.
(n) Use the Docker Image policy plugin – This plugin is designed to prevent any process from
pulling images that were not previously allow-listed.
(o) Enable TLS everywhere – enable TLS for all supported components to defend against traffic

sniffing and authenticate identities at both ends of each connection.
(p) Use a service mesh architecture – Service meshes are networks of persistent encrypted
connections between high-performance sidecar proxies. They provide traffic monitoring,

management and policy enforcement without affecting microservices.
(q) Use OPA – Open Policy Agent (OPA) enforces custom policies on a Kubernetes object without
reconfiguring or recompiling the Kubernetes API server.
(r) Apply network policies – The default Kubernetes networking permits all traffic between pods,
but can be restricted with a network policy.

(s) Implement private networks – Deploy each Kubernetes worker and master node on a private

subnet to secure the connections to corporate networks, make nodes unreachable from the public
Internet and minimise overall attack surface.

(t) Keep the etcd cluster separate – Use a firewall to protect the etcd cluster, which stores state
and secret information and requires special protection compared to other Kubernetes
components.
(u) Ensure the regular rotation of encryption keys – Regularly rotating encryption keys and
certificates helps minimise the blast radius of an attack that compromises keys.

(v) Use static analysis for YAML – Statically analyse where pod security policies deny access to
API servers. This should be part of the development workflow because it helps identify the
organisation’s risk tolerance and conformity requirements.

(w) Manage secrets – Integrate clusters using a secret management system to ensure application
pods automatically receive all secrets and passwords needed at runtime (based on the app roles

87