Open droopy4096 opened 1 year ago
This would be a great feature for bpfman :/
In our usecase we have applications which can run with runAsNonRoot: true
and
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
However the applications also need to be able to access a volume provisioned by bpfman in an unprivileged manner, meaning the fs/user groups need to be set accordingly requiring a custom SCC like the following
---
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name: bpfman-restricted
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: false
allowPrivilegedContainer: false
allowedCapabilities: null
defaultAddCapabilities: null
groups: []
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- ALL
runAsUser:
type: RunAsAny
seLinuxContext:
type: RunAsAny
seccompProfiles: null
supplementalGroups:
type: MustRunAs
fsGroup:
type: RunAsAny
volumes:
- configMap
- csi
- downwardAPI
- emptyDir
- ephemeral
- persistentVolumeClaim
- projected
- secret
IMO the operator should be able to create this SCC for users to consume.
Feature Request
reposting from https://github.com/operator-framework/operator-sdk/issues/6004 as per https://github.com/operator-framework/operator-sdk/issues/6004#issuecomment-1230690162
Describe the problem you need a feature to resolve.
as could be seen from GitLab issue - it is unnecessary hard to distribute operator as OLM bundle when one cannot include SCC (unlike
Roles
,RoleBindings
,ClusterRoles
andClusterRoleBindings
andServiceAccounts
that comprise RBAC stack in generick8s
cluster).Having additional steps negates simplicity that OLM has to offer in terms of distribution and management as now packaged operators depend on unpackaged features that require their own lifecycle management applied.
Describe the solution you'd like.
Allow
SecurityContextConstraints
to be part of CSV and distributed with OLM bundles.