apps: require either letsencrypt or a seperate issuer

[kristiangronas]

Warning

This is a public repository, ensure not to disclose:

• personal data beyond what is necessary for interacting with this pull request, nor
• business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• kind/feature
• kind/improvement
• kind/deprecation
• kind/documentation
• kind/clean-up
• kind/bug
• kind/other

Optional: Mark one or more of the following that are applicable:

Important

Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

• kind/admin-change
• kind/dev-change
• kind/security
• [kind/adr](set-me)

What does this PR do / why do we need this PR?

There needs to be a clusterissuer, but some users may have their own issuer like sectigo or harica

Information to reviewers

You can test the fetching manually with yajsv

Checklist

• Proper commit message prefix on all commits
• Change checks:
  • The change is transparent
  • The change is disruptive
  • The change requires no migration steps
  • The change requires migration steps
  • The change updates CRDs
  • The change updates the config and the schema
• Documentation checks:
  • The public documentation required no updates
  • The public documentation required an update - [link to change](set-me)
• Metrics checks:
  • The metrics are still exposed and present in Grafana after the change
  • The metrics names didn't change (Grafana dashboards and Prometheus alerts required no updates)
  • The metrics names did change (Grafana dashboards and Prometheus alerts required an update)
• Logs checks:
  • The logs do not show any errors after the change
• PodSecurityPolicy checks:
  • Any changed Pod is covered by Kubernetes Pod Security Standards
  • Any changed Pod is covered by Gatekeeper Pod Security Policies
  • The change does not cause any Pods to be blocked by Pod Security Standards or Policies
• NetworkPolicy checks:
  • Any changed Pod is covered by Network Policies
  • The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • The change does not cause any unnecessary Kubernetes audit events
  • The change requires changes to Kubernetes audit policy
• Falco checks:
  • The change does not cause any alerts to be generated by Falco
• Bug checks:
  • The bug fix is covered by regression tests

[anders-elastisys]

Thanks for the contribution!
I am not an expert on configuring the schema, but I did some testing to ensure that it gets validated when letsencrypt is enabled, which is the default in Welkin. I added some comments with suggestions that seemed to achieve what you wanted.

[kristiangronas]

Ah thanks, i think i assumed that extraIssuers would be unset completely instead of an empty array

[anders-elastisys]

The unit tests complains about missing title and description, could you add this as well? :)

[anders-elastisys]

Seems to also be complaining about missing description for this

[Zash]

I am a little bit worried about the security and performance of fetching these over the Internet, which is why we haven't done it like this before. Not sure how to proceed with that.

[kristiangronas]

The performance shouldn't really be noticable, but it might not work in an airgapped situation

Security-wise i'm not too worried, although it's probably a good idea to pin a commit hash

Another way to do it is $ref: "file://./compliantkubernetes-apps/config/schemas/clusterissuer_v1.json", just have to switch directory before running yajsv, could maybe do it with a submodule as well to reduce maintenance burden?

[Zash]

One way I looked at before was to pass referenced schemas via yajsv -r path/to/schemas, but at the time decided against because it made local references exceedingly verbose as they needed to be absolute URLs (matching the $id of the referenced schemas)