Reduce or document the CSI node driver writable host-root mount

Open
  • Is something wrong?
#553 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
kubernetes
Domain
infrastructure, security

Research direction

Start with the host-root volumeMount and the hostPath: / volume in the oci-csi-node-driver.yaml asset from the v1.36.0 release. Then check the driver source to see which host paths the node plugin actually touches for block volume, FSS, and Lustre. Done means a maintainer confirms the root mount is required or a narrower read-only path list is proposed and accepted. This needs a design decision, so confirm scope in the thread before writing any change.

Written by the indexing model from the issue text.

Description

Is this a BUG REPORT or FEATURE REQUEST?

FEATURE REQUEST / clarification

Versions

CCM Version: v1.36.0

Environment:

  • Kubernetes version: 1.36
  • OS: Oracle Linux managed worker nodes
  • Others: OCI CSI node driver deployed by OKE

What happened?

The public v1.36.0 oci-csi-node-driver.yaml release asset mounts the worker host's entire root filesystem into the privileged oci-csi-node-driver container:

volumeMounts:
  - mountPath: /host
    mountPropagation: HostToContainer
    name: host-root
# ...
volumes:
  - hostPath:
      path: /
      type: Directory
    name: host-root

The mount is writable because readOnly is not set. This gives the CSI node-driver container broader host filesystem access than its explicit /dev, /var/lib/kubelet, plugin, and registration mounts.

Oracle's current OKE storage documentation says the CSI volume plugin "does not require access to underlying operating system and root file system dependencies." A prior OKE-rendered CSI node DaemonSet also demonstrated that a narrower set of explicit host paths is technically possible, but a later provider-managed rollout returned to the public manifest's writable host-root shape.

What you expected to happen?

Please clarify whether the writable host-root mount is intentionally required by the OCI CSI node driver, and which operation needs it (block volume/iSCSI, FSS, Lustre, encryption, or another path).

If it is not required, please replace it with the minimum explicit host paths and read-only flags needed by the supported storage operations. If it is required for only some storage modes, please provide a supported configuration that omits the root mount when those modes are disabled.

It would also help to document whether OKE users with no PV/PVC usage can safely disable or replace this built-in CSI deployment without losing supported cluster behavior.

How to reproduce it (as minimally and precisely as possible)?

  1. Download the oci-csi-node-driver.yaml asset from the public v1.36.0 release.
  2. Inspect the oci-csi-node-driver container's host-root volume mount and the corresponding hostPath.path: / volume.

Release: https://github.com/oracle/oci-cloud-controller-manager/releases/tag/v1.36.0

Anything else we need to know?

This request is about least privilege and supported configuration, not a claim that the image is untrusted or that exploitation has occurred. The current DaemonSet can be healthy while still exposing a broader host boundary than necessary.

Dominant language
Go
Stars
160
Forks
109
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from oracle/oci-cloud-controller-manager

All issues in oracle/oci-cloud-controller-manager

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.