confidential-containers / cloud-api-adaptor

Ability to create Kata pods using cloud provider APIs aka the peer-pods approach
Apache License 2.0
47 stars 79 forks source link

cloud-config: streamline credentials provisioning #1850

Closed mkulke closed 2 months ago

mkulke commented 4 months ago

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 commented 4 months ago

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.

mkulke commented 2 months ago

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

huoqifeng commented 2 months ago

@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 https://github.com/confidential-containers/cloud-api-adaptor/pull/1912

mkulke commented 2 months ago

@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