-
Notifications
You must be signed in to change notification settings - Fork 15
Kubewarden v1
Flavio Castelli edited this page May 13, 2022
·
1 revision
Feature | Blocking v1? |
---|---|
Policy Reports | No |
Background checks | No |
Context-aware policies | No |
Grandfathered feature? | Tentative yes |
Richer SDKs? | No |
Missing SDKs? | No |
Missing upgrade e2e? | Tentative no |
~~ - Include verify-image-signatures
policy in kubewarden-defaults
? ~~
~~ - Have two policy servers? Signed and unsigned ~~
~~ - Easier for users running their own policies ~~
**Update:** we don’t think we should have this policy added to the default ones, there aren’t yet many container images signed with sigstore. The risk of breaking a cluster is too high.
Sign our own artifacts:
Component | Mandatory | Notes |
---|---|---|
kwctl binaries | Yes | |
policy server container image | Yes | |
kubewarden controller container image | Yes | |
Helm | Tentative yes | Research how mature/viable is to helm install from an OCI registry |
Blocker: tentative no
Component | Blocking v1? | Notes |
---|---|---|
CRDs | tentative yes + “tag” new version | Transition from alpha to beta |
Helm charts | no | |
CLI arguments | no |
Should we fix all issues? Tentative no
Tentative no. Controller bugs?
- Reorg: tentative yes
- Better visibility of some parts of the docs (CRDs reference)
- Specification of the QA’d upgrade path (v1.2.3 -> 1.3.0 -> 1.3.1…)
- Kubewarden stack: minor/major bumps would be the only ones bumping all components. Patchlevel move at their own pace, they don’t need to be in sync.
- helm-chart has own versioning: tentative yes
- UI is versioned along with Kubewarden: tentative yes, using public API
- Best effort + what is supported by CI
Do they have what they need?
Nothing to be done in this regard