Validate and sanitize input to the `OperatingSystemConfiguration`

[MrBatschner]

How to categorize this issue?

/area os
/kind enhancement
/os suse-chost

What would you like to be added:

For this extension, when using an OS image of type memoryone-chost, it is possible to supply configuration parameters by means of an OperatingSystemConfiguration.

apiVersion: memoryone-chost.os.extensions.gardener.cloud/v1alpha1
kind: OperatingSystemConfiguration
memoryTopology: "2"
systemMemory: "6x"

Right now, this configuration only supports the fields memoryTopology and systemMemory but both fields are strings. This comes with two drawbacks:

• Should someone provide a non-string input to one of the fields (i.e. an unquoted 2 for memoryTopology which will be treated as an integer), the extension will fail to unmarshal this YAML into its corresponding go structs. This happens fairly late in tthe Shoot reconcilation process ultimately causing it to fail and affects new as well as existing clusters
• These fields can be used to inject arbitrary values by just seperating them via ; (something like memoryTopology: "2;feature_enable=0x4" - we already saw that in the wild). Since these values ultimately end up in the user-data that gets supplied to the cloud-providers, not sanitizing the input is a potential security risk.

As a result, this extensions should provide an input validation that will reject an input that is invalid or potentially malicious so that it gets caught early and does not interfere with the reconcilation of Shoot clusters.

Why is this needed:

explained above

[MrBatschner]

Issue is treated with low priority and if it is implemented, we must take special care not to break any user workload that is in fact relying on being able to inject additional configuration parameters through the value of an existing parameter (ref xkcd).

[Roncossek]

This input validation could be implemented as a validating web-hook.

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all issues.
This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close

/lifecycle rotten

[gardener-robot]

@gardener-ci-robot Command /add is not available to you but only to a Maintainer, Member, Author.