Initial access Execution Persistence Privilege escalation Defense evasion Credential access Discovery Lateral movement Collection Impact
Using Cloud Exec into Container Backdoor Container Privileged Container Clear Container Logs List K8s secrets Access the K8s API server Access cloud resources Images from a private repository Data Destruction
Compromised images in registry bash/cmd in container Writable hostPath mount Cluster-admin binding Delete k8s events Mount service principal Access Kubelet API Container service account Ressource hijacking
Kubeconfig file New container Kubernetes CronJob hostPath mount Pod / container name similarity Access container service account Network mapping Cluster internal networking Denial of Service
Application vulnerability Application exploit (RCE) Malicious admission controller Access cloud resources Connect from proxy server Applications credentials in configuration files Access Kubernetes dashboard Applications credentials in configuration files
Exposed sensitive interfaces SSH server running in inside container Disable Namespacing Access managed identity credentials Instance metadata API Writable volume mounts on the host
Sidecar injection Malicious admission controller CoreDNS poisoning
ARP poisoning and IP spoofing

SSH server running in inside container

SSH server that is running inside a container may be used by attackers. If attackers gain valid credentials to a container, whether by brute force attempts or by other methods (such as phishing), they can use it to get remote access to the container by SSH.

Example

The following is a pod that runs an SSH server:

apiVersion: v1
kind: Pod
metadata:
  name: openssh-server
spec:
  containers:
  - image: linuxserver/openssh-server:latest
    name: openssh-server
    env:
    - name: SUDO_ACCESS
      value: "true"
    - name: PASSWORD_ACCESS
      value: "true"
    - name: USER_NAME
      value: "demo"
    - name: USER_PASSWORD
      value: "dontDoThisInProd!"
    ports:
    - containerPort: 2222

This container can now be accessed by any other container in the cluster (assuming there are no network policies that forbid this). The situation could get even worse when the SSH service is exposed to systems outside of the cluster.

References