Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploying in Openshift shows permission issues #517

Open
andreagianfreda opened this issue Oct 14, 2022 · 1 comment
Open

Deploying in Openshift shows permission issues #517

andreagianfreda opened this issue Oct 14, 2022 · 1 comment

Comments

@andreagianfreda
Copy link

Installing with Helm charts shows the following permission issues:

chmod: /var/lib/influxdb2: Operation not permitted
chmod: /var/lib/influxdb2: Operation not permitted
chmod: /etc/influxdb2: Operation not permitted
....
Error: **setup succeeded, but failed to write new config to local path**: open /etc/influxdb2/influx-configs: permission denied
2022-10-14T14:21:33.	warn	cleaning bolt and engine files to prevent conflicts on retry	{"system": "docker", "bolt_path": "/var/lib/influxdb2/influxd.bolt", "engine_path": "/var/lib/influxdb2"}

Here https://docs.openshift.com/container-platform/4.2/openshift_images/create-images.html#images-create-guide-openshift_create-images:

Support arbitrary user ids

By default, OpenShift Container Platform runs containers using an arbitrarily assigned user ID. This provides additional security against processes escaping the container due to a container engine vulnerability and thereby achieving escalated permissions on the host node.

For an image to support running as an arbitrary user, directories and files that may be written to by processes in the image should be owned by the root group and be read/writable by that group. Files to be executed should also have group execute permissions.

Adding the following to your Dockerfile sets the directory and file permissions to allow users in the root group to access them in the built image:

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory
@putz612
Copy link

putz612 commented Dec 20, 2022

I was able to get around this one by creating a new scc and adding the service account to it. You will need to change the line user line to reflect your deployment. The service account should match your helm deployment name but to confirm you can use
# oc get serviceaccount

uid1000.yaml

kind: SecurityContextConstraints
apiVersion: security.openshift.io/v1
metadata:
  annotations:
    kubernetes.io/description: Only for things that like UID 1000
  name: uid1000
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
priority: 10
readOnlyRootFilesystem: false
requiredDropCapabilities:
- MKNOD
- KILL
- SYS_CHROOT
- SETUID
- SETGID
runAsUser:
  type: MustRunAs
  uid: 1000
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
users: 
#####
## Change the line below to reflect your deployment
#####
- system:serviceaccount:< project/namespace >:< service account >
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret

Then you will have to run the scc in
# oc create -f uid1000.yaml
Trash the existing pod to pick up the new scc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants