I am starting with kubernetes and need to migrate some existing docker apps. We are using internal NAS .
Current Scenario
I have a docker app running as svc-appuser and NAS drive is exported to the docker host on /nas/data/appname for svc-appuser. So the app can access nas folder without any issues during bootup. Docker-compose looks like below.
version: '2'
services:
App-server:
image: ln03:9000/App:1.0.0
restart: on-failure
cap_add:
- SYS_ADMIN
- DAC_READ_SEARCH
environment:
SSL_KEYSTORE_PASSWORD: ${ssl_keystore_password}
SSL_KEY_ALIAS: ${ssl_key_alias}
volumes:
- /nas/data/appname:/opt/appdata
Now in kubernetes, I was reading that we have to create Persistent volume claim (pvc) before deploying application and then use this pvc in yaml file for app deployment.
The docker daemon is run as svc-dockeradmin user. I assume that my Dockerfile to build the image will still be same , i.e
FROM ubuntu:latest
ARG PROXY_HOST
ARG PROXY_PORT
.
.
.
USER svc-appuser
CMD [ "sh", "-c", "/entrypoint.sh; bash"]
My question is how do we get it working in my case.
Until and unless I create the pvc as svc-appuser, there is no way the app can use it after bootup. How do I do that.
I referred Kubernetes-NFS-example and no info there.
PS : The NAS share is already mounted on all hosts for svc-appuser
As per documentation:
Due to an unresolved bug in the Go archive/tar package’s handling of sparse files, attempting to create a user with a significantly large UID inside a Docker container can lead to disk exhaustion because /var/log/faillog in the container layer is filled with NULL (\0) characters. A workaround is to pass the --no-log-init flag to useradd. The Debian/Ubuntu adduser wrapper does not support this flag.
More examples how to manage with defined users inside Dockerfile
RUN useradd -r -u 1001 -g appuser appuser
USER appuser
Note:
The USER instruction sets the user name (or UID) and optionally the user group (or GID) to use when running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile. Warning: When the user doesn’t have a primary group then the image (or the next instructions) will be run with the root group.
Please note that CAP_SYS_ADMIN
gives additional privileges:
AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the no_new_privs flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has CAP_SYS_ADMIN.
On the other hand, you pleae read about Configure a Security Context for a Pod or Container and Access control
Hope this helped, in other case - please convert your files into proper k8s yamls so community members will be able to elaborate more deeply with your case.