cloud-config: streamline credentials provisioning

[mkulke]

Instead of nesting it into a daemon.json property for the forwarder the auth file is being moved to its own entry, which will simplify the logic and allow cloud-init based podvms to use authenticated registries without running process-user-data alongside cloud-init.

[mkulke]

according to the discussion on the linked guest-component issue, we might end up having to add an image_registry_auth_file param back to kata to make this work, since there are provisions to change the path in image-rs's ImageConfig and unless we want to go around and sneak in an override path via env or something, we'd have to specify it at the owner of the ImageConfig, which is kata agent.

[stevenhorsman]

I'm happy with moving the destination path for auth.json and removing it out of daemon.json, but I have a question on how we might be able to use it in image-rs

[mkulke]

some changes need to be applied once #1933 has been merged

[stevenhorsman]

Code LGTM. Thanks!

[bpradipt]

/lgtm

[huoqifeng]

@mkulke I'm wondering how was this file get provisioned?

SrcAuthfilePath = "/root/containers/auth.json"

Is this something can be introduced in initdata? Like in PR #1912

[mkulke]

@mkulke I'm wondering how was this file get provisioned?

SrcAuthfilePath = "/root/containers/auth.json"

Is this something can be introduced in initdata? Like in PR #1912

this is part of the kustomize install routine, an auth.json gets mounted to the CAA daemonset container at this path