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.

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

Support for Encryption Providers #769

Closed
containerpope opened this issue Dec 22, 2019 · 1 comment
Closed

Support for Encryption Providers #769

containerpope opened this issue Dec 22, 2019 · 1 comment
Assignees
Labels
Epic kind/feature Categorizes issue or PR as related to a new feature. sig/cluster-management Denotes a PR or issue as being assigned to SIG Cluster Management.
Milestone

Comments

@containerpope
Copy link

What feature would you like to be added?
KubeOne should implement support for providing a Kubernetes Encryption provider to ensure, that no Kubernetes secrets are stored in cleartext in etcd.

This can be achieved by setting the --encryption-provider-config flag on the Kubernetes API Server and pointing it to the location of an EncryptionConfiguration yaml file.

This is an example config from the docs:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: <BASE 64 ENCODED SECRET>
    - identity: {}

Editing the config allows enabling encryption, disabling encryption and rotating keys. No further logic is required beside changing the content of the file.

How could this be implemented?
Implementing this would require KubeOne to copy the config to the /etc/kubernetes folder and setting the flag on the api server. If a KubeOne upgrade is triggered, the hashes of the config files could be compared to detect changes or the file is just copied without checking, KubeOne refreshes the config on the masters and restarts the api servers.

A good approach might be the following structure under the KubeOne feature config:

features:
  # Enables the KubernetesEncryptionProvider that ensures, that secrets are only 
  # stored encrypted inside etcd
  secretEncryption:
    enabled: true
    encryptionConfig: "/path/to/config.yaml"

This would ensure, that a user can provide the config from outside easily and is able to rotate keys and other stuff, because he has control over the config.

What are use cases of the feature?

  • All secrets are stored encrypted in etcd
  • Users can easily plugin in other KMS systems for secret encryption
  • Users can use the key based secret encryption option
  • Users have full control over how the secrets are encrypted, when the keys are rotated or which provider is used

Useful Links:

@containerpope containerpope added the kind/feature Categorizes issue or PR as related to a new feature. label Dec 22, 2019
@kron4eg kron4eg added this to the v1.1 milestone Mar 27, 2020
@moelsayed moelsayed self-assigned this Jan 5, 2021
@moelsayed moelsayed added the Epic label Jan 12, 2021
@xmudrii xmudrii added the sig/cluster-management Denotes a PR or issue as being assigned to SIG Cluster Management. label Jan 20, 2021
@moelsayed
Copy link
Contributor

We are already working on this, but with a different perspective. The proposal for the implementation is tracked in #1212.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic kind/feature Categorizes issue or PR as related to a new feature. sig/cluster-management Denotes a PR or issue as being assigned to SIG Cluster Management.
Projects
None yet
Development

No branches or pull requests

5 participants