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

[dewe]

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: ebefedf#diff-76ed074a9305c04054cdebb9e9aad2d818052b07091de1f20cad0bbac34ffb52R58

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

[mvisser-nhb]

+1 I have the same issue

[CodeReaper]

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>