aboutsummaryrefslogtreecommitdiff
path: root/docs/source/markdown/podman-generate-kube.1.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/source/markdown/podman-generate-kube.1.md')
-rw-r--r--docs/source/markdown/podman-generate-kube.1.md6
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 41545455e..3586341a9 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