k3s/pkg/cloudprovider
Kubernetes Submit Queue 0d17e9deb7 Merge pull request #48574 from sakshamsharma/kms-transformer
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
```
2017-08-29 11:11:10 -07:00
..
providers Merge pull request #48574 from sakshamsharma/kms-transformer 2017-08-29 11:11:10 -07:00
BUILD Use buildozer to delete licenses() rules except under third_party/ 2017-08-11 09:32:39 -07:00
OWNERS Proposal to add @wlan0 to appropriate owner files 2017-08-17 11:37:51 -07:00
README.md
cloud.go Merge pull request #51087 from oracle/for/upstream/master/ccm-instance-exists 2017-08-26 06:43:30 -07:00
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.