In my last article “Closing the Kubernetes security gap” I raised the question: how secure is Kubernetes?
In particular, the effects of the increasing scale of container deployment in 2018. Now, as Kubernetes grows ever popular, four areas have been identified as the key areas to watch when security poses itself as a threat.
1. Application and environment misconfigurations
One area that could be exposed to security threat is misconfigurations (vulnerable containers). Indeed, not paying attention to configurations could prove a risk as more organisations deploy containerised applications in production environments.
In a risky misconfiguration environment, Kubernetes containers running in pods may become targets for attackers who are searching for weaknesses. Once unauthorised connections between pods has been established, applications could be disrupted, or sensitive data may become accessible.
Ultimately, well configured environments that are not under surveillance may prove to have a huge impact on the number of vulnerabilities.
2. Container-level issues
Despite misconfigurations and other issues in an environment, a vulnerable container can lead to bigger problems, as Marc Feghali, founder and VP of product management at Attivo Networks, explains:
“If attackers compromise a container, they can attempt to escalate privileges to take control of additional containers or the entire cluster…If attackers compromise a privileged container or steal credentials with privileges to manage the Kubernetes cluster, they can cause a great deal of damage by accessing the cluster and any data traffic between containers. This can lead to data theft or resource-hijacking.”
3. The orchestrator itself as a target
Kubernetes infrastructure is also prone to an attack. Attackers can attack its resources, including API server or Kubelets.
Indeed, “Attackers can then proceed to leverage privilege escalation mechanisms that enable them to gain cluster admin privileges from a compromised container.”
Specifically, one example of a popular attack vector is cryptocurrency mining. Conducting sophisticated attacks to target sensitive data and try to use Kubernetes apps as a doorway into other systems.
4. Mind what production deployments expose
It is important to make the distinction between running Kubernetes in a test or dev environment and running it in production. They are not the same, especially from a security perspective when production deployments are confronted with misconfigurations.
One argument is that there will be an increase in runtime threats that will be undetectable until they move to production. As the amount of deployments being moved into production grows, the migration will increase the volume of vulnerable workloads at runtime.
Moving to containers and orchestration will require new security practices and tools, which will be benefited if a good DevOps culture already exits. However, it is important to note that Secure in dev does not mean it is secure everywhere.
“Understanding the full lifecycle of the container and all the dependencies has to be something done with the collaboration of development, testing, OT/IT, and security. The dependencies between any testing and production environment differ greatly and therefore the old adage that you can test [and] secure in dev and it’ll work in PROD are no longer valid.”
Roberts at Attivo Networks
In conclusion,
it is evident that these areas are likely to be most commonly endangered by
security issues. But there is a silver lining here, although Kubernetes will
always be targeted by attackers, as the Kubernetes user community grows, so
will its ability to actively remove these vulnerabilities before it can be put
to malicious use.
