Threat Modelling- Pod Attack vectors

Necessity of a rootless mode in Pod based deployment

Normally pod based deployments follow a structure as mentioned above. Pods are hosted or deployed on the Node based EKS clusters.

Applications that are deployed as part of containerized images are part of pods. Here, Application level vulnerabilities such as

1. Command or Code injection
2. Insecured Deserialization
3. SQL/DB injection

above vulnerabilities prominently are vulnerabilities that multiplies or impacts more based on the underlying infrastructure hardening levels.

Lets Assume , we have an application that is accepting a code as input for configuration and it is hosted as pod based deployment on the EKS cluster.

Attack Vector as described for such use cases:

As IDE offers custom code creation, it needs to harden and accept only the commands/instruction
that are necessary perform the operation however, as it is accepting all other operations too, it is
possible to get system level user passwords and usernames using simple file operations in .net.
above code snippet is the exploitation of the path traversal vulnerability and confidential /sensitive
data exposure vulnerability.

This way

1. All the passwords under /etc/passwd can be retrieved and can be read
2. User can be added by opening a file /etc/passwd
3. Any file can be accessed this way, modified, and can be replaced with malware, malicious
   contents that can be executed by any other job or scheduler as part of scheduling activities.
   Example : Any crown job or executable file can be accessed once the location is enumerated,
   modified with malware or malicious contents which after replacement becomes malware in
   itself causing disastrous effects for all the organization.
   Impacts : Impact of this vulnerability is disastrous/Very Critical category.
   The user which is created can be used as persistent access and can gain
4. As end user has access to a file system on the server, end user can manipulate any
   executable job, can replace the contents of the job, can create a malware, can delete
   sensitive files etc.
5. End user can then gain persistent access using Kubernetes secrets.
6. Access to EKS secrets and this way can compromise the whole AWS infrstructure too.

Remediation of Pod level attack vectors to avoid in such scenarios:

1. Pod – Enable Runtime Protection “The pods should be equipped with runtime protection mechanisms to detect and prevent any malicious activities
2. Pod – Enforce a POD execution policy Defining the POD execution policy will prevent known attacks. There are 3 policies which you can implement 1. Privileged Baseline Restricted
   • And 3 modes of execution which you can
     • implement,Enforce,AuditWarn.Reference: https://aws.github.io/aws-eks-best-practices/security/docs/pods/
3. Pod – Establish secure communication between pods and other resources “Use secure communication protocols such as TLS to encrypt network traffic and prevent eavesdropping or tampering
4. Pod – Provide limited pod privilege “The pods should be granted the minimum privileges necessary to perform their intended functions, in order to reduce the potential attack surface
5. Pod – Resource quotas should be defined “Resource isolation and limitations such as using resource quotas and limits to prevent resource exhaustion or denial of service attacks
6. Pod – Restrict Linux Capabilities for an user “Pods that are run as privileged, inherit all of the Linux capabilities associated with root on the host. This should be avoided
   • Reference: https://aws.github.io/aws-eks-best-practices/security/docs/pods/”
7. Pod – Restrict write operations of pods and pod status “Enable the NodeRestriction admission plugin to limit a kubelet to modify pods bound to itself
   • Reference: https://aws.github.io/aws-eks-best-practices/security/docs/pods/“