search

confidential-containers / cloud-api-adaptor

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

kata-containers should be at the same level #977

Open surajssd opened 1 year ago

surajssd commented 1 year ago

We don't mention this that kata-containers repository should be at the same level as CAA repository in the Azure documentation. We should do that.

Or we completely switch to building from a docker image. But I wonder how the az login will work from the CI 🤔.

katexochen commented 1 year ago

Or we completely switch to building from a docker image.

I'd say this is a good idea. Having two ways to do something often leads to situations where things only work/are tested on one way.

surajssd commented 1 year ago

Or we completely switch to building from a docker image.

I'd say this is a good idea. Having two ways to do something often leads to situations where things only work/are tested on one way.

I agree. Just that when we use the local credentials of the az cli we may have to mount ~/.azure directory so that packer can use that.

katexochen commented 1 year ago

Why can't we mount the env variables into the container instead, as we already do in the current container building workflow?

surajssd commented 1 year ago

Why can't we mount the env variables into the container instead, as we already do in the current container building workflow?

We can expose it like that. What about the way in which local credential support is needed? When we don't create a service principal but use the local credentials that user already has, fetched via az login, packer can use them to do the build. We are adding support for that feature here: https://github.com/confidential-containers/cloud-api-adaptor/pull/973.

This is also a desirable feature for the Azure provider CI for CAA. There we are not creating any service principal we are using managed identity. So we don't have any "secrets". But the gh action for azure login does some magic and fetches the credentials and saves it locally in the ~/.azure directory. Now the packer running inside the container may not have access to this folder, so we should make this accessible to the container.