Security Disclaimer:
Adding a sudo user introduces security vulnerabilities by granting elevated privileges within the containerized environment. Exercise caution and consider the security implications before implementing this solution. This is a no-no solution for production. Please refer to the following blogs for further insights into this topic:
This blog post outlines the process of adding a sudo user to a Red Hat OpenAI (RHOAI) Workbench container image. Whether building the image from scratch using a Containerfile or utilizing a pre-built image, the steps provided here ensure the inclusion of a sudo user for enhanced permissions within the containerized environment.
- Build the Container image using Containerfile file. The important part is. You can also use pre-built image which is published here
quay.io/bpandey/rhoai-workbench:sudo-jupyteruser-v3
USER 0
RUN echo "sudoers: files" >> /etc/nsswitch.conf
RUN dnf install -y sudo
RUN echo "default ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
- Create notebook using notebook.yaml file. Make sure to replace namespace, container image, OCP domain name. You can also create a workbench from RHOAI ui and patch following lines later.
securityContext:
allowPrivilegeEscalation: true
runAsGroup: 1001
runAsUser: 1001
One issue I've encountered with the patch is the following error message.
[I 2024-05-06 18:27:50.042 ServerApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[E 2024-05-06 18:27:50.042 ServerApp] Failed to write server-info to /opt/app-root/src/.local/share/jupyter/runtime/jpserver-13.json: PermissionError(13, 'Permission denied')
Traceback (most recent call last):
File "/opt/app-root/bin/jupyter-lab", line 8, in <module>
sys.exit(main())
File "/opt/app-root/lib64/python3.9/site-packages/jupyter_server/extension/application.py", line 617, in launch_instance
serverapp.start()
File "/opt/app-root/lib64/python3.9/site-packages/jupyter_server/serverapp.py", line 2952, in start
self.start_app()
File "/opt/app-root/lib64/python3.9/site-packages/jupyter_server/serverapp.py", line 2856, in start_app
self.write_browser_open_files()
File "/opt/app-root/lib64/python3.9/site-packages/jupyter_server/serverapp.py", line 2723, in write_browser_open_files
self.write_browser_open_file()
File "/opt/app-root/lib64/python3.9/site-packages/jupyter_server/serverapp.py", line 2746, in write_browser_open_file
with open(self.browser_open_file, "w", encoding="utf-8") as f:
PermissionError: [Errno 13] Permission denied: '/opt/app-root/src/.local/share/jupyter/runtime/jpserver-13-open.html'
[INFO 2024-05-06 18:27:52.152 TabnineDownloader]: Finish download Tabnine Binary to /opt/app-root/lib/python3.9/site-packages/jupyterlab_tabnine/binaries/4.159.0/x86_64-unknown-linux-musl
The root cause of this error is that the /opt/app-root/src/ directory is persistent. When you launch the workbench from the RHOAI UI for the first time, it creates this directory with a random user. After applying the patch, we attempt to run the workbench as user 1001, which causes permission conflicts. To address this, we could implement an initialization script to resolve the permission issue automatically.
initContainers:
- name: fix-permissions
image: registry.access.redhat.com/ubi8/python-39:1-176.1712880517
command: ["sh", "-c", "chown -R default:1001 /opt/app-root/src/"]
securityContext:
runAsUser: 0
allowPrivilegeEscalation: false
volumeMounts:
- mountPath: /opt/app-root/src
name: sudo-jupyteruser
Alternatively, we could create the workbench using the notebook.yaml file from the outset, eliminating this issue altogether
- Add SCC profile
oc adm policy add-scc-to-user privileged -z sudo-jupyteruser
Top comments (0)