/etc/ssl mount with read and write permissions

[jkossak]

Rancher Server Setup

Rancher v2.7.1, Kubernetes Version: v1.24.10, RKE2 v1.24.9+rke2r2.
Installation option: Helm

Information about the Cluster

Kubernetes version: 1.24.10
Cluster Type: Downstream - 1 node with three roles: etcd, cp and worker
The cluster is installed on Ubuntu 22.04 VM

User Information

When editing the system-upgrade-controller pod I noticed the /etc/ssl directory on the host is mounted to the container with read and write permissions.

root@rancl:~# kubectl describe pod system-upgrade-controller-79fc9c84b7-gfk8r -n cattle-system
Name:         system-upgrade-controller-79fc9c84b7-gfk8r
Namespace:    cattle-system
Priority:     0
Node:         ranchercl/10.237.213.143
Start Time:   Thu, 16 Feb 2023 23:09:39 +0000
Labels:       pod-template-hash=79fc9c84b7
              upgrade.cattle.io/controller=system-upgrade-controller
Annotations:  cni.projectcalico.org/containerID: c07d81240c0f76f03c9fc862de83c8a795d9b7f4ff4c6ea097ce0f8047605e7c
              cni.projectcalico.org/podIP: 10.42.174.212/32
              cni.projectcalico.org/podIPs: 10.42.174.212/32
              k8s.v1.cni.cncf.io/network-status:
                [{
                    "name": "k8s-pod-network",
                    "ips": [
                        "10.42.174.212"
                    ],
                    "default": true,
                    "dns": {}
                }]
              k8s.v1.cni.cncf.io/networks-status:
                [{
                    "name": "k8s-pod-network",
                    "ips": [
                        "10.42.174.212"
                    ],
                    "default": true,
                    "dns": {}
                }]
              kubernetes.io/psp: global-unrestricted-psp
Status:       Running
IP:           10.42.174.212
IPs:
  IP:           10.42.174.212
Controlled By:  ReplicaSet/system-upgrade-controller-79fc9c84b7
Containers:
  system-upgrade-controller:
    Container ID:   containerd://9105398f6b785d8953bcec8048a383934bd5e16f305797fb4a056cee77717b26
    Image:          rancher/system-upgrade-controller:v0.9.1
    Image ID:       docker.io/rancher/system-upgrade-controller@sha256:558cd0cf45f245afe31c99b9a7bc2f2235f7f317b545e2fdabc5ad28af1a0fe5
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Thu, 16 Feb 2023 23:09:45 +0000
    Ready:          True
    Restart Count:  0
    Environment Variables from:
      system-upgrade-controller-config  ConfigMap  Optional: false
    Environment:
      SYSTEM_UPGRADE_CONTROLLER_NAME:        (v1:metadata.labels['upgrade.cattle.io/controller'])
      SYSTEM_UPGRADE_CONTROLLER_NAMESPACE:  cattle-system (v1:metadata.namespace)
    Mounts:
      /etc/ssl from etc-ssl (rw)
      /tmp from tmp (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-4nxwm (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  etc-ssl:
    Type:          HostPath (bare host directory volume)
    Path:          /etc/ssl
    HostPathType:  Directory
  tmp:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  kube-api-access-4nxwm:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 op=Exists
Events:                      <none>

I wonder if and why the write permissions are required by the system-upgrade-controller container, if read permissions would be enough. Is the system-upgrade-controller expected to modify the certificates inside /etc/ssl on the host? Ability to modify the certificates in /etc/ssl may cause potential threads.

[iMikeG6]

Hi,
good catch.

I changed the volumeMounts by adding readOnly: true on the deployment on our clusters
Only tmp hasn't been modified, as it doesn't have such a big impact, though, I'm still wondering if it's really necessary and if this can be replaced by an emptyDir volume instead. I might be wrong, i don't know, as I'm not a developer.

          volumeMounts:
            - name: etc-ssl
              readOnly: true
              mountPath: /etc/ssl
            - name: etc-pki
              readOnly: true
              mountPath: /etc/pki
            - name: etc-ca-certificates
              readOnly: true
              mountPath: /etc/ca-certificates
            - name: tmp
              mountPath: /tmp

With this, our operating systems are still up to date using SUC.
As for upgrading k3s or other rancher distros with SUC, I can't tell you, as we are using RKE2 and manually updating them using rancher. Whished that rancher has autoupdate features...