Why can I cd /root in a pod container even after specifying proper "securityContext"?

2/25/2022

I have a helm chart with deployment.yaml having the following params:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: {{ .Values.newAppName }}
    chart: {{ template "newApp.chart" . }}
    release: {{ .Release.Name }}
  namespace: {{ .Release.Namespace }}
  name: {{ .Values.deploymentName }}
spec:
  replicas: {{ .Values.numReplicas }}
  selector:
    matchLabels:
      app: {{ .Values.newAppName }}
  template:
    metadata:
      labels:
        app: {{ .Values.newAppName }}
      namespace:  {{ .Release.Namespace }}
      annotations:
        some_annotation: val
        some_annotation: val
    spec:
      serviceAccountName: {{ .Values.podRoleName }}
      containers:
      - env:
        - name: ENV_VAR1
          value: {{ .Values.env_var_1 }}
        image: {{ .Values.newApp }}:{{ .Values.newAppVersion }}
        imagePullPolicy: Always
        command: ["/opt/myDir/bin/newApp"]
        args: ["-c", "/etc/config/newApp/{{ .Values.newAppConfigFileName }}"]
        name: {{ .Values.newAppName }}
        ports:
        - containerPort: {{ .Values.newAppTLSPort }}
          protocol: TCP
        livenessProbe:
          httpGet:
            path: /v1/h
            port: {{ .Values.newAppTLSPort }}
            scheme: HTTPS
          initialDelaySeconds: 1
          periodSeconds: 10
          timeoutSeconds: 10
          failureThreshold: 20
        readinessProbe:
          httpGet:
            path: /v1/h
            port: {{ .Values.newAppTLSPort }}
            scheme: HTTPS
          initialDelaySeconds: 2
          periodSeconds: 10
          timeoutSeconds: 10
          failureThreshold: 20
        volumeMounts:
        - mountPath: /etc/config/newApp
          name: config-volume
          readOnly: true
        - mountPath: /etc/config/metrics
          name: metrics-volume
          readOnly: true
        - mountPath: /etc/version/container
          name: container-info-volume
          readOnly: true
      - name: {{ template "newAppClient.name" . }}-client
        image: {{ .Values.newAppClientImage }}:{{ .Values.newAppClientVersion }}
        imagePullPolicy: Always
        args: ["run", "--server", "--config-file=/newAppClientPath/config.yaml", "--log-level=debug", "/newAppClientPath/pl"]
        volumeMounts:
        - name: newAppClient-files
          mountPath: /newAppClient-path
      securityContext:
        fsGroup: 1000
        runAsNonRoot: true
        runAsUser: 1000
      volumes:
      - name: config-volume
        configMap:
          name: {{ .Values.newAppConfigMapName }}
      - name: container-info-volume
        configMap:
          name: {{ .Values.containerVersionConfigMapName }}
      - name: metrics-volume
        configMap:
          name: {{ .Values.metricsConfigMapName }}
      - name: newAppClient-files
        configMap:
          name: {{ .Values.newAppClientConfigMapName }}
          items:
            - key: config
              path: config.yaml
            
          

This helm chart is consumed by Jenkins and then deployed by Spinnaker onto AWS EKS service.

A security measure that we ensure is that /root directory should be private in all our containers, so basically it should deny permission when a user tries to manually do the same after

kubectl exec -it -n namespace_name pod_name -c container_name bash

into the container.

But when I enter the container terminal why can I still

cd /root

inside the container when it is running as non-root?

EXPECTED: It should give the following error which it is not giving:

cd root/

bash: cd: root/: Permission denied

OTHER VALUES THAT MIGHT BE USEFUL TO DEBUG: Output of "ls -la" inside the container:

dr-xr-x--- 1 root root 18 Jul 26 2021 root

As you can see the r and x SHOULD BE UNSET for OTHER on root folder

Output of "id" inside the container:

bash-4.2$ id uid=1000 gid=0(root) groups=0(root),1000

Using a helm chart locally to reproduce the error ->

The same 3 securityContext params when used locally in a simple Go program helm chart yields the desired result.

Deployment.yaml of helm chart:

apiVersion: {{ template "common.capabilities.deployment.apiVersion" . }}
kind: Deployment
metadata:
  name: {{ template "fullname" . }}
  labels:
    chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ template "fullname" . }}
  template:
    metadata:
      labels:
        app: {{ template "fullname" . }}
    spec:
      securityContext:
        fsGroup: 1000
        runAsNonRoot: true
        runAsUser: 1000
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        ports:
        - containerPort: {{ .Values.service.internalPort }}
        livenessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        readinessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        resources:
{{ toYaml .Values.resources | indent 12 }}

Output of ls -la inside the container on local setup:

drwx------ 2 root root 4096 Jan 25 00:00 root

-- Sparsh Prasad
kubernetes
kubernetes-helm
root

1 Answer

2/25/2022

You can always cd into / in the UNIX system as non-root, so you can do it inside your container as well. However, e.g. creating a file there should fail with Permission denied.

Check the following.

# Run a container as non-root
docker run -it --rm --user 7447 busybox sh
# Check that it's possible to cd into '/'
cd /
# Try creating  file
touch some-file
touch: some-file: Permission denied
-- RafaƂ Leszko
Source: StackOverflow