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.

Sign up for GitHub

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

Add note about volume with unprivileged container #12301

Merged
merged 1 commit into from
Nov 22, 2021
+14 −0
Merged

Add note about volume with unprivileged container #12301

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions docs/source/markdown/podman-generate-kube.1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
8 changes: 8 additions & 0 deletions pkg/domain/infra/abi/generate.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,6 +124,14 @@ func (ic *ContainerEngine) GenerateKube(ctx context.Context, nameOrIDs []string,
if err != nil {
return nil, err
}
if len(po.Spec.Volumes) != 0 {
warning := `
# NOTE: If you generated this yaml from an unprivileged and rootless podman container on an SELinux
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this something we can know? We know if we're rootless, and AFAIK the SELinux package has the ability to check if we're enabled

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could check for that and add the privileged: true option, but that would be assuming the user wants to run a privileged container. We could add a warning that we made it privileged due to volumes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well the spec file could be shared with people on a different system with SELinux enabled.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we doing this in podman generate kube, now that I think about this? This mostly seems like an issue for podman play kube - shouldn't we warn people there, given the problems show up when the YAML is run?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It shows up when we run the yaml in a kubernetes cluster, so makes more sense to put the warning on the generate side.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The note will be added to the generated yaml, so users should see it when using it in a kubernetes cluster or with play kube.

# enabled system, check the podman generate kube man page for steps to follow to ensure that your pod/container
# has the right permissions to access the volumes added.
`
content = append(content, []byte(warning))
}
b, err := generateKubeYAML(libpod.ConvertV1PodToYAMLPod(po))
if err != nil {
return nil, err
Expand Down