-
Notifications
You must be signed in to change notification settings - Fork 98
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
📖 Add documentation on how to gate upgrades with kyverno #1135
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -72,6 +72,70 @@ system-upgrade apply-os-upgrade-on-kairos-with-1a1a24bcf897bd275730bdd8548-h7f | |
|
||
Done! We should have all the basics to get our first cluster rolling, but there is much more we can do. | ||
|
||
## Verify images attestation during upgrades | ||
|
||
Container images can be signed during the build phase of a CI/CD pipeline using [Cosign](https://github.com/sigstore/cosign), Kairos signs every artifact as part of the release process. | ||
|
||
To ensure that the images used during upgrades match the expected signatures, [Kyverno](https://kyverno.io/) can be used to set up policies. This is done by checking if the signature is present in the OCI registry and if the image was signed using the specified key. The policy rule check fails if either of these conditions is not met. | ||
|
||
To learn more about this specific Kyverno feature, you can refer to the [documentation](https://kyverno.io/docs/writing-policies/verify-images/). This allows for the verification of image authenticity directly at the node level prior to upgrading. | ||
|
||
A Kyverno policy for `provider-kairos` images might look like the following: | ||
|
||
```yaml | ||
apiVersion: kyverno.io/v1 | ||
kind: ClusterPolicy | ||
metadata: | ||
name: check-image | ||
spec: | ||
validationFailureAction: Enforce | ||
background: false | ||
webhookTimeoutSeconds: 30 | ||
failurePolicy: Fail | ||
rules: | ||
- name: check-image | ||
match: | ||
any: | ||
- resources: | ||
kinds: | ||
- Pod | ||
verifyImages: | ||
- imageReferences: | ||
- "quay.io/kairos/kairos-*" | ||
attestors: | ||
- entries: | ||
# See: https://kyverno.io/docs/writing-policies/verify-images/#keyless-signing-and-verification | ||
- keyless: | ||
subject: "https://github.com/kairos-io/provider-kairos/.github/workflows/release.yaml@refs/tags/*" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is kind of icky. Hear me out, this is really good until cosign or the CI breaks and we need to sign the already published artifacts in a different way, maybe by a different workflows like we used to do in that other project. Then this doesnt match anymore so you either drop a release completely as it wont be signed, resign it and break this gating for users or run a new release and left the unsigned release there. does this subject allows for regex? or for value.in so we can provide a list? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. that's a valid and good point the subject is a regex already indeed: |
||
issuer: "https://token.actions.githubusercontent.com" | ||
rekor: | ||
url: https://rekor.sigstore.dev | ||
``` | ||
|
||
To install Kyverno in a Kairos cluster, you can simply use the community [bundles](/docs/advanced/bundles). For example, you can use the following installation cloud config file: | ||
|
||
```yaml | ||
#cloud-config | ||
|
||
hostname: kyverno-{{ trunc 4 .MachineID }} | ||
|
||
# Specify the bundle to use | ||
bundles: | ||
- targets: | ||
- run://quay.io/kairos/community-bundles:system-upgrade-controller_latest | ||
- run://quay.io/kairos/community-bundles:cert-manager_latest | ||
- run://quay.io/kairos/community-bundles:kyverno_latest | ||
|
||
users: | ||
- name: kairos | ||
passwd: kairos | ||
|
||
k3s: | ||
enabled: true | ||
``` | ||
|
||
This configuration file prepare the system with the `cert-manager`, `system-upgrade-controller` and the `kyverno` bundle, enabling `k3s`. | ||
|
||
## Customize the upgrade plan | ||
|
||
It is possible to run additional commands before the upgrade takes place into the node, consider the following example: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We ened to rename this asap :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep indeed... we have #711 in the sprint :) , I would have waited for #711, but this list in the docs was not matching the truth since a long time already, so thought to updated it