ValidatingAdmissionPolicy for C-0012

[suhasgumma]

Control C-0012

Related Resources: Workloads and ConfigMaps

Control Docs: https://hub.armosec.io/docs/c-0012

Control Rego:

• https://github.com/kubescape/regolibrary/blob/master/rules/rule-credentials-in-env-var/raw.rego
• https://github.com/kubescape/regolibrary/blob/master/rules/rule-credentials-configmap/raw.rego

[slashben]

@suhasgumma , I think there might be an issue with the way you handle environment variables. (correct me if I am wrong)

An environment variable can have a value defined in the pod spec, or it can get its value from a secret or a configmap.

For example, I have an environment variable "AWS_SECRET_KEY" defined in the pod spec. If it has an immediate value specified in the Pod spec it should fail the control/policy. If it is mounted from a Kubernetes secret it is good practice!
See here: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables

[suhasgumma]

An environment variable can have a value defined in the pod spec, or it can get its value from a secret or a configmap.

• Yes @slashben, you are right. But, the policy will not fail if the value is mounted by a secret or configMap. We are checking for them indirectly.

• If the value is not set or set to a non-empty string, only then secretKeyRef or configMapKeyRef can be defined.

• If the value is not set or set to a non-empty string, the control will pass regardless. So, we don't need to check if there is a secretKeyRef or configMapKeyRef set.

• I think it is unclear for anyone, shall we add logic checking for secretKeyRef or configMapKeyRef just for the purpose of documentation?

[slashben]

You can add comment to the policy itself, no?

[suhasgumma]

You can add comment to the policy itself, no?

Yeah, I will do that and clearly specify it in the documentation too.

[matthyx]

@suhasgumma can you rebase and fix conflicts?