Skip to content
This repository has been archived by the owner on Oct 21, 2022. It is now read-only.

Disallow Privileged Container #78

Open
CodeClinch opened this issue Apr 8, 2019 · 2 comments
Open

Disallow Privileged Container #78

CodeClinch opened this issue Apr 8, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@CodeClinch
Copy link
Contributor

CodeClinch commented Apr 8, 2019

Description

From Kubernetes v1.1, any container in a pod can enable privileged mode, using the privileged flag on the SecurityContext description. This feature is only necessary for a few selected use cases. It should be possible to restrict this flag to the selected namespaces.

User Story

As an administrator, I would like to disable the usage of privileged containers. If it is still necessary I would like to restrict it to a selected namespace.

Implementation idea

The validating webhook should reject pods that have the privileged flag set to true if they are not part of a selected namespace (namespace with allowed privileged containers).

Will be solved with #159.

@CodeClinch CodeClinch added the enhancement New feature or request label Apr 8, 2019
@marwinski
Copy link
Contributor

Well, an alternative way to do this is pod security policies. Before we are going to build an alternative mechanism we may want to weigh the pros-and cons of this. My gut feeling is that this feature is useful but I believe we need to understand the consequences.

@ionysos ionysos self-assigned this May 22, 2019
@ionysos ionysos removed their assignment Jul 1, 2019
@ionysos
Copy link
Contributor

ionysos commented Jul 1, 2019

Containers are by default unprivileged which fits perfectly to our current secure-by-default approach with karydia.
Thus, we'll decided to go with the current K8s default and consider a suitable solution for later releases of karydia.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants