diff options
| author | Urvashi Mohnani <umohnani@redhat.com> | 2021-11-15 10:05:42 -0500 |
|---|---|---|
| committer | Matthew Heon <mheon@redhat.com> | 2021-12-06 15:17:57 -0500 |
| commit | 4a7af72ea95bd6ebba19db8d052527c5beb9c0eb (patch) | |
| tree | dd39ddc6bd2c005e0b6f255451f4420b0c598767 /docs/source | |
| parent | ca518ecdee6fba52e9e9a464a4915a4caaa3081b (diff) | |
| download | podman-4a7af72ea95bd6ebba19db8d052527c5beb9c0eb.tar.gz podman-4a7af72ea95bd6ebba19db8d052527c5beb9c0eb.tar.bz2 podman-4a7af72ea95bd6ebba19db8d052527c5beb9c0eb.zip | |
Add note about volume with unprivileged container
Add a note to the generated kube yaml if we detect a
volume is being mounted. The note lets the user know
what needs to be done to avoid permission denied error
when trying to access the volume for an unprivileged
container.
Add the same note to the man pages.
NO NEW TESTS NEEDED
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Diffstat (limited to 'docs/source')
| -rw-r--r-- | docs/source/markdown/podman-generate-kube.1.md | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/docs/source/markdown/podman-generate-kube.1.md b/docs/source/markdown/podman-generate-kube.1.md index a583afcf9..0add97144 100644 --- a/docs/source/markdown/podman-generate-kube.1.md +++ b/docs/source/markdown/podman-generate-kube.1.md @@ -19,6 +19,12 @@ Potential name conflicts between volumes are avoided by using a standard naming Note that if an init container is created with type `once` and the pod has been started, the init container will not show up in the generated kube YAML as `once` type init containers are deleted after they are run. If the pod has only been created and not started, it will be in the generated kube YAML. Init containers created with type `always` will always be generated in the kube YAML as they are never deleted, even after running to completion. +*Note*: When using volumes and generating a Kubernetes YAML for an unprivileged and rootless podman container on an **SELinux enabled system**, one of the following options must be completed: + * Add the "privileged: true" option to the pod spec + * Add `type: spc_t` under the `securityContext` `seLinuxOptions` in the pod spec + * Relabel the volume via the CLI command `chcon -t container_file_t context -R <directory>` +Once completed, the correct permissions will be in place to access the volume when the pod/container is created in a Kubernetes cluster. + Note that the generated Kubernetes YAML file can be used to re-run the deployment via podman-play-kube(1). ## OPTIONS |