mirror of https://github.com/k3s-io/k3s
![]() Automatic merge from submit-queue Add Google cloud KMS service for envelope encryption transformer This adds the required pieces which will allow addition of KMS based encryption providers (envelope transformer). For now, we will be implementing it using Google Cloud KMS, but the code should make it easy to add support for any other such provider which can expose Decrypt and Encrypt calls. Writing tests for Google Cloud KMS Service may cause a significant overhead to the testing framework. It has been tested locally and on GKE though. Upcoming after this PR: * Complete implementation of the envelope transformer, which uses LRU cache to maintain decrypted DEKs in memory. * Track key version to assist in data re-encryption after a KEK rotation. Development branch containing the changes described above: https://github.com/sakshamsharma/kubernetes/pull/4 Envelope transformer used by this PR was merged in #49350 Concerns #48522 Planned configuration: ``` kind: EncryptionConfig apiVersion: v1 resources: - resources: - secrets providers: - kms: cachesize: 100 configfile: gcp-cloudkms.conf name: gcp-cloudkms - identity: {} ``` gcp-cloudkms.conf: ``` [GoogleCloudKMS] kms-location: global kms-keyring: google-container-engine kms-cryptokey: example-key ``` |
||
---|---|---|
.. | ||
providers | ||
BUILD | ||
OWNERS | ||
README.md | ||
cloud.go | ||
doc.go | ||
plugins.go |
README.md
Deprecation Notice: This directory has entered maintenance mode and will not be accepting new providers. Cloud Providers in this directory will continue to be actively developed or maintained and supported at their current level of support as a longer-term solution evolves.
Overview:
The mechanism for supporting cloud providers is currently in transition: the original method of implementing cloud provider-specific functionality within the main kubernetes tree (here) is no longer advised; however, the proposed solution is still in development.
Guidance for potential cloud providers:
- Support for cloud providers is currently in a state of flux. Background information on motivation and the proposal for improving is in the github proposal.
- In support of this plan, a new cloud-controller-manager binary was added in 1.6. This was the first of several steps (see the proposal for more information).
- Attempts to contribute new cloud providers or (to a lesser extent) persistent volumes to the core repo will likely meet with some pushback from reviewers/approvers.
- It is understood that this is an unfortunate situation in which 'the old way is no longer supported but the new way is not ready yet', but the initial path is unsustainable, and contributors are encouraged to participate in the implementation of the proposed long-term solution, as there is risk that PRs for new cloud providers here will not be approved.
- Though the fully productized support envisioned in the proposal is still 2 - 3 releases out, the foundational work is underway, and a motivated cloud provider could accomplish the work in a forward-looking way. Contributors are encouraged to assist with the implementation of the design outlined in the proposal.
Some additional context on status / direction:
- 1.6 added a new cloud-controller-manager binary that may be used for testing the new out-of-core cloudprovider flow.
- Setting cloud-provider=external allows for creation of a separate controller-manager binary
- 1.7 adds extensible admission control, further enabling topology customization.