KamusEncryptionRequest Object?

[Yshayy]

It might be useful to create an encryption request object (CRD) in a similar way to CSR (certificate signing request) flow (https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#create-a-certificate-signing-request-object-to-send-to-the-kubernetes-api) which can be automated by the cli (or other tools).

The flow will allow Kamus-cli to leverage k8s and kubectl security model (connectivity to cluster, RBAC) and will remove the need to expose the encrypt-api. (although it's possible to get part of this functionality by having the cli proxying the encryption-api)

It can also allow users to easily create a KamusEncryptionRequest resource in k8s UIs and then copy the result to their VCS which can be useful for #152 .

[omerlh]

Sounds interesting, it's basically adding another CRD to the controller. PR is welcomed :)
An alternative is to write a plugin to kubectl, which is similar to this approach.

[Yshayy]

I think the controller flow sort of bypass the encrypt api and provide a process that is more secure. (there's audit, transport security, RBAC out-of-the-box and it resilient to DOS attacks)

[Yshayy]

Although it adds more coupling to k8s

[omerlh]

All the controller is k8s only, so it's ok. In the future, we can make it deployed only on k8s envs...
Anyway, now that the controller is deployed, adding another CRD is relatively simple.

[Yshayy]

Is Kamus designed (or planned) to work in non-k8s environments?

[omerlh]

Yep, see #112. This is the long term plan, looking for people to work with on the design.

[Yshayy]

With the controller in place, does deployments need to create ConfigMaps explictly? (or configmaps are created from KamusSecret)

[omerlh]

ConfigMap is for using the init container, the controller creates vanilla Kubernetes secrets from a KamusSecret object. Those are for different purposes - see the docs for more details.

[Yshayy]

Hmmm, theoretically the init container can read/mount the CRD, or the CRD can create an encrypted ConfigMap for the init container (the same way it creates unencrypted secret).
It’ll make a the KamusSecret the origin object for encrypted data.

This developer flow could be something like -> create KamusEncryptionRequest resource (via cli/kubectl/dashboard) -> KamusSecret is created by the controller, (request is purged) -> developer adds the resource yaml to source control (for GitOps) and can optionally add binding (secret/configmap) in spec.

[omerlh]

Not sure it will make the flow simpler, I think it is better to add auto injection feature to the init container. Anyway, if you'd like a PR will be appreciated.