bitnami-labs / sealed-secrets

A Kubernetes controller and tool for one-way encrypted Secrets
Apache License 2.0
7.68k stars 683 forks source link

SealedSecret resources from kubeseal do not conform with the openapi schema in the CRD #1320

Open dewe opened 1 year ago

dewe commented 1 year ago

Which component: kubeseal version: v0.23.1

Describe the bug SealedSecrets from kubeseal contains the field .spec.template.metadata.creationTimestamp: null, which is not accepted by the CRD schema when tested with kubeconform (https://github.com/yannh/kubeconform).

To Reproduce Steps to reproduce the behavior:

  1. Convert the CRD OpenAPI file to a JSON schema in a local file, as described here:

    $ wget -q https://raw.githubusercontent.com/yannh/kubeconform/master/scripts/openapi2jsonschema.py
    $ python openapi2jsonschema.py https://raw.githubusercontent.com/bitnami-labs/sealed-secrets/release/v0.23.1/helm/sealed-secrets/crds/bitnami.com_sealedsecrets.yaml
    JSON schema written to sealedsecret_v1alpha1.json
  2. Create a sample sealed secret:

    echo -n bar | kubectl create secret generic mysecret --dry-run=client --from-file=foo=/dev/stdin -o json | kubeseal > mysealedsecret.json
  3. Run the kubeconform, checking the schema

    $ kubeconform -schema-location='{{ .ResourceKind }}_{{ .ResourceAPIVersion }}.json' mysealedsecret.json
    
    mysealedsecret.json - SealedSecret mysecret is invalid: problem validating schema. Check JSON formatting: jsonschema: '/spec/template/metadata' does not validate with file:///Users/dewe/bitbucket/postnord/eks/tmp/test-schemas/sealedsecret_v1alpha1.json#/properties/spec/properties/template/properties/metadata/additionalProperties: additionalProperties 'creationTimestamp' not allowed

    In output above you find: ... properties/spec/properties/template/properties/metadata/additionalProperties: additionalProperties 'creationTimestamp' not allowed

Expected behavior CRD OpenAPI schema should accept SealedSecrets created by kubeseal. With previous versions of SealedSecrets, kubeconform did not complain about the resource being invalid.

Additional context I'd guess it's this change that's the root cause: https://github.com/bitnami-labs/sealed-secrets/commit/ebefedf91530ec6311e9ba863d5265d9beeeb273#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52R58

Currently we workaround this problem by adding -skip SealedSecret to kubeconform.

mvisser-nhb commented 9 months ago

+1 I have the same issue

CodeReaper commented 7 months ago

Currently we workaround this problem by adding -skip SealedSecret to kubeconform.

We ran into the same issue, but I wanted to share our workaround in case anyone else could benefit of it. Instead of skipping validation we are opting to sanitize the input with yq (this approach could also have some drawbacks).

<generate or print manifests> | yq 'del(.metadata.creationTimestamp)' | kubeconform <arguments>