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

Feature/new secret backend vault transit #826

Merged
merged 52 commits into from
Apr 12, 2022
Merged

Feature/new secret backend vault transit #826

merged 52 commits into from
Apr 12, 2022

Conversation

Moep90
Copy link
Contributor

@Moep90 Moep90 commented Mar 1, 2022

Proposed Changes

  • add vaulttransit as new secret engine
  • add tests to vaulttransit secret engine for encryption, decryption
  • add documentation for the new secret engine
  • this will allow to use the Hashicorp Vaults Secret Engine called Transit
    • usage is similar to GKMS but with vault
    • you can encrypt, decrypt secrets
    • you can use different policies like engineers can encrypt secrets but not decrypt them
    • a key rotation using the same key is allowed and would reencrypt the secrets
    • changing the key will reencrypt the secrets using the kapitan reencrypt way

@Moep90 Moep90 marked this pull request as ready for review March 1, 2022 06:52
@Moep90
Copy link
Contributor Author

Moep90 commented Mar 9, 2022

tests seams to be fixed with #828

danny.heinrich and others added 24 commits March 18, 2022 06:53
This change needs to be merged first: kapicorp/reclass#7

* On the latest version, to render helm template it now uses the helm
  cli directly. However it seems using helm 3.8.0 (the latest stable),
  the default behavior if to release name is specify is to populate with
  the string "release-name", not "RELEASE-NAME" hence all lowercase.
  There's a simple way to reproduce:
  ```
  helm create test-chart
  helm template --include-crds --skip-tests
  ````
  And check how {{ .Release.Name }} gets populated when there's none
  specified.

Signed-off-by: Lionel H <me@nullbyte.be>
)

The content-type `application/gzip` has been introduced in [RFC 6713][1]
as an official type which was intendend to be used instead of various
custom content types, such as `application/x-gzip`.

It appears that adoption of `application/gzip` is not very high, so its
absence from the list of content types which Kapitan tries to unpack
hasn't caused issues yet.

However, we've now found a dependency (Cilium Enterprise Edition OLM
manifests) which is served with `content-type: application/gzip` which
results in the following log messages from Kapitan:

```
Dependency https://<REDACTED>/cilium-ee-1.10.4.tar.gz: fetching now
Dependency https://<REDACTED>/cilium-ee-1.10.4.tar.gz: successfully fetched
Dependency https://<REDACTED>/cilium-ee-1.10.4.tar.gz: Content-Type application/gzip is not supported for unpack. Ignoring save
```

This commit adds `application/gzip` as a supported content type for
`.tar.gz` archives in `unpack_downloaded_file()`.

[1]: https://datatracker.ietf.org/doc/html/rfc6713
@Moep90 Moep90 requested a review from ramaro March 18, 2022 07:58
@ramaro
Copy link
Member

ramaro commented Apr 12, 2022

This is good to go, thanks @Moep90 @xqp !

@ramaro ramaro merged commit 28916cf into kapicorp:master Apr 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants