Windows Daemonset not starting under Openshift due to SCC
Hi, using 24.10.0 or 24.06 under Openshift 4.16 with Windows Nodes. The operator successfully creates the "trident-node-windows" SCC.
allowHostPorts: false
priority: null
requiredDropCapabilities:
- MKNOD
allowPrivilegedContainer: false
runAsUser:
type: RunAsAny
users:
- 'system:serviceaccount:trident:trident-node-windows'
allowHostDirVolumePlugin: false
allowHostIPC: false
seLinuxContext:
type: MustRunAs
readOnlyRootFilesystem: false
metadata:
annotations:
kubernetes.io/description: 'trident-node-windows is a clone of the anyuid built-in, and is meant just for use with trident.'
resourceVersion: '1736544975'
name: trident-node-windows
uid: ff45ad32-0fb0-42af-aeff-1c2cd8367ae4
creationTimestamp: '2024-11-18T09:19:22Z'
- apiVersion: trident.netapp.io/v1
controller: true
kind: TridentOrchestrator
name: trident
uid: 02250c41-f783-430b-9292-181888c15926
labels:
app: node.csi.trident.netapp.io
fsGroup:
type: RunAsAny
groups: []
kind: SecurityContextConstraints
defaultAddCapabilities: null
supplementalGroups:
type: RunAsAny
volumes:
- downwardAPI
- emptyDir
- projected
allowHostPID: false
allowHostNetwork: false
allowPrivilegeEscalation: true
apiVersion: security.openshift.io/v1
allowedCapabilities: null
The windows Pod from the Daemonset cant start though, because the SCC does not allow "hostPath". The linux scc created by Trident does allow it.
@philipp1992 Could you please confirm if Trident 23.x version was working fine with no hostPath issues ? Also please share the SCC with Trident 23.x
error still present with version 25.06.0
Following SCC will be created for Windows, within volumes "hostPath" is missing and allowHostDirVolumePlugin must be "true"
allowHostPorts: false
priority: null
requiredDropCapabilities:
- MKNOD
allowPrivilegedContainer: false
runAsUser:
type: RunAsAny
users:
- 'system:serviceaccount:trident:trident-node-windows'
allowHostDirVolumePlugin: false
allowHostIPC: false
seLinuxContext:
type: MustRunAs
readOnlyRootFilesystem: false
metadata:
annotations:
kubernetes.io/description: 'trident-node-windows is a clone of the anyuid built-in, and is meant just for use with trident.'
resourceVersion: '16735391'
name: trident-node-windows
uid: dc4b1699-091a-466e-bc0a-766d34c9e518
creationTimestamp: '2025-06-30T09:20:33Z'
generation: 1
managedFields:
- apiVersion: security.openshift.io/v1
fieldsType: FieldsV1
fieldsV1:
'f:seLinuxContext':
.: {}
'f:type': {}
'f:readOnlyRootFilesystem': {}
'f:metadata':
'f:annotations':
.: {}
'f:kubernetes.io/description': {}
'f:labels':
.: {}
'f:app': {}
'f:ownerReferences':
.: {}
'k:{"uid":"b795a4de-aab7-4d91-b976-748573a23ee2"}': {}
'f:groups': {}
'f:supplementalGroups':
.: {}
'f:type': {}
'f:allowHostPID': {}
'f:allowHostNetwork': {}
'f:allowPrivilegeEscalation': {}
'f:users': {}
'f:runAsUser':
.: {}
'f:type': {}
'f:allowHostPorts': {}
'f:requiredDropCapabilities': {}
'f:allowPrivilegedContainer': {}
'f:allowHostDirVolumePlugin': {}
'f:fsGroup':
.: {}
'f:type': {}
'f:allowHostIPC': {}
manager: trident-operator
operation: Update
time: '2025-06-30T09:21:06Z'
- apiVersion: security.openshift.io/v1
fieldsType: FieldsV1
fieldsV1:
'f:volumes': {}
manager: Mozilla
operation: Update
time: '2025-06-30T09:30:54Z'
ownerReferences:
- apiVersion: trident.netapp.io/v1
controller: true
kind: TridentOrchestrator
name: trident
uid: b795a4de-aab7-4d91-b976-748573a23ee2
labels:
app: node.csi.trident.netapp.io
fsGroup:
type: RunAsAny
groups: []
kind: SecurityContextConstraints
defaultAddCapabilities: null
supplementalGroups:
type: RunAsAny
volumes:
- downwardAPI
- emptyDir
- projected
allowHostPID: false
allowHostNetwork: false
allowPrivilegeEscalation: true
apiVersion: security.openshift.io/v1
allowedCapabilities: null
This issue is fixed in Trident 25.10.