Currently, karydia inverts insecure defaults which help to have a secure by default cluster. In the next step, kardiya should provide the possibility to reject pods that cannot be validated against a policy.
These two features (“Secure by default” and “Policy check”) should be enabled separately. In a development cluster, one would like to have “Secure by default” only in a build environment both scenarios will be enabled.
Settings to be checked:
Service account token is not mounted
Privileged: false
HostNetwork: false
Seccomp assigned with value = “docker/default”
No root user
Do not mount “/”
Do not user default namespace
Used images (white / blacklist)
Mandatory image repository
Needed configuration:
feature switch on/off
customizing of single checks (on/off and values)
Roles:
There should be two roles a developer who has to fulfill the policy and a "superuser" who can allow exceptions.
User Story
As administrator I want to have a policy to keep my clusters clean in order to have a decent level of security but it should be possible to allow an exception.
[OPTIONAL] Implementation idea
For some of the checks, PSP can be used others could be implemented as a mutating webhook. It might be necessary that we have to define developer roles and superuser roles and include them in the installation procedure.
Description
Currently, karydia inverts insecure defaults which help to have a secure by default cluster. In the next step, kardiya should provide the possibility to reject pods that cannot be validated against a policy.
These two features (“Secure by default” and “Policy check”) should be enabled separately. In a development cluster, one would like to have “Secure by default” only in a build environment both scenarios will be enabled.
Settings to be checked:
Needed configuration:
Roles: There should be two roles a developer who has to fulfill the policy and a "superuser" who can allow exceptions.
User Story
As administrator I want to have a policy to keep my clusters clean in order to have a decent level of security but it should be possible to allow an exception.
[OPTIONAL] Implementation idea
For some of the checks, PSP can be used others could be implemented as a mutating webhook. It might be necessary that we have to define developer roles and superuser roles and include them in the installation procedure.