CABPK - ignition - files defined with base64 encoding are not decoded on the disk

[calvix]

What steps did you take and what happened:
When using ignition. If you define a file in KubeAdmSpec.Files with encoding: base64 the resulting file on disk is still base64 encoded.

Example of configuration:

- path: /test-file
  permissions: "0600"
  encoding: base64
  content: dGhpcyBpcyBwbGFpbiB0ZXh0

The resulting file on disk has contents:

$ cat /test-file
dGhpcyBpcyBwbGFpbiB0ZXh0

What did you expect to happen:

$ cat /test-file
this is plain text

Environment:

• Cluster-api version: 1.1.3
• OS (e.g. from /etc/os-release): Flatcar Container Linux by Kinvolk 3033.2.2 (Oklo)

/kind bug

[calvix]

cc @invidian

[fabriziopandini]

/area bootstrap
/milestone v1.2

[invidian]

/assign invidian

I'll have a look into it today.

[invidian]

Hmm, as far as I see, neither Flatcar's Ignition or CLC currently support gzip compression, see flatcar/container-linux-config-transpiler#13. Perhaps @jepio or @pothos could confirm.

But the config transpiler should support specifying input files in base64 format, though this is currently not supported by our cloud-init to CLC conversion code. I checked the code and I see that ownership handling has also been omitted, we should fix that as well.

I see the following tasks then:

• Deal with gzip compression, we can either:
  • Reject configs with content encoding gzip or gzip+base64 when Ignition is requested on validation webhook level. Not so great for the users though.
  • Decompress content while generating Ignition configuration. This should cover more user cases, however since the compression won't be applied, resulting Ignition size will be larger than the cloud-init equivalent, which may still make it fail in certain environments (where user data size is limited). We may also run into issues on the controller side, like unpacking very large inputs or something.
• Deal with base64 encoding, we can:
  • Add support for encoding: base64 in CLC code. This is trivial, just a template change + tests.
  • Reject it on validation webhook level (not recommended, annoying for users and the implementation of support shouldn't be too difficult)
• Fix handling files ownership (perhaps separate issue should be created to work on that).
  • This will be more complex to implement, as write_files cloud-init module support simply root:root passed to chown as far as I remember, while CLC takes more structured user.name or user.id or group.name or group.id, so we will have to do some splitting and number parsing.

I'd appreciate some input on what to work on then.

Right now, as a workaround, additional base64 encoded files can be specified using CLC snippet instead:

Old:

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
spec:
  kubeadmConfigSpec:
    files:
    - path: /test-file
      permissions: "0600"
      encoding: base64
      content: dGhpcyBpcyBwbGFpbiB0ZXh0

New:

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
spec:
  kubeadmConfigSpec:
    ignition:
      containerLinuxConfig:
        additionalConfig: |
          storage:
            files:
            - path: /test-file
              mode: 0600
              contents:
                inline: !!binary |
                  dGhpcyBpcyBwbGFpbiB0ZXh0

[jepio]

Base64 is supported by ignition/ct, gzip is explicitly unsupported in older ignition (https://github.com/flatcar-linux/ignition/blob/flatcar-master/internal/resource/url.go#L270-L272) but supported in new ignition (https://github.com/flatcar-linux/ignition/blob/main/internal/resource/url.go#L341-L346). That requires using butane.

So base64 could be supported right now with fixes to the code, but I would not do transparent ungzipping.

[invidian]

If there is no further feedback, I'll create a PR with the fixes as suggested.

[invidian]

WIP PR with the fixes: #6472

[sbueringer]

/area bootstrap