Fixes: #7573
To enable this feature, build your rootfs using AGENT_POLICY=yes. The
default is AGENT_POLICY=no.
Building rootfs using AGENT_POLICY=yes has the following effects:
1. The kata-opa service gets included in the Guest image.
2. The agent gets built using AGENT_POLICY=yes.
After this patch, the shim calls SetPolicy if and only if a Policy
annotation is attached to the sandbox/pod. When creating a sandbox/pod
that doesn't have an attached Policy annotation:
1. If the agent was built using AGENT_POLICY=yes, the new sandbox uses
the default agent settings, that might include a default Policy too.
2. If the agent was built using AGENT_POLICY=no, the new sandbox is
executed the same way as before this patch.
Any SetPolicy calls from the shim to the agent fail if the agent was
built using AGENT_POLICY=no.
If the agent was built using AGENT_POLICY=yes:
1. The agent reads the contents of a default policy file during sandbox
start-up.
2. The agent then connects to the OPA service on localhost and sends
the default policy to OPA.
3. If the shim calls SetPolicy:
a. The agent checks if SetPolicy is allowed by the current
policy (the current policy is typically the default policy
mentioned above).
b. If SetPolicy is allowed, the agent deletes the current policy
from OPA and replaces it with the new policy it received from
the shim.
A typical new policy from the shim doesn't allow any future SetPolicy
calls.
4. For every agent rpc API call, the agent asks OPA if that call
should be allowed. OPA allows or not a call based on the current
policy, the name of the agent API, and the API call's inputs. The
agent rejects any calls that are rejected by OPA.
When building using AGENT_POLICY_DEBUG=yes, additional Policy logging
gets enabled in the agent. In particular, information about the inputs
for agent rpc API calls is logged in /tmp/policy.txt, on the Guest VM.
These inputs can be useful for investigating API calls that might have
been rejected by the Policy. Examples:
1. Load a failing policy file test1.rego on a different machine:
opa run --server --addr 127.0.0.1:8181 test1.rego
2. Collect the API inputs from Guest's /tmp/policy.txt and test on the
machine where the failing policy has been loaded:
curl -X POST http://localhost:8181/v1/data/agent_policy/CreateContainerRequest \
--data-binary @test1-inputs.json
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
(cherry picked from commit ab829d1038)
Note: this is cherrypicked to help with the following:
- Provide a building block to continue experimenting with policy and identify issues at the earliest.
This is especially helpful for remote hypervisor (peer-pods) as currently we have no way to test
this feature and identify areas of improvements as part of merge to main.
- Provide a building building block to prototype and understand any potential gaps or integration
issues with the initdata specification discussed in the following issue - https://github.com/confidential-containers/confidential-containers/issues/171
There are no tests for this feature in CCv0 branch and you should use it at your own risk.
Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
The pullimage handler behaves differently for the sandbox and container,
and it uses the annotations to differentiate between the two.
The annotation name used by crio for container-type being different than
the containerd one, we need to check both.
Fixes: #8399
Signed-off-by: Julien Ropé <jrope@redhat.com>
The release candidates for image-rs, AA, and td-shim have
now been tagged with v0.8.0. Point the respective toml
and yaml files to this tag.
Fixes: #8352
Signed-off-by: Chris Porter <porter@ibm.com>
Restricting access to agent endpoints using agent-config.toml is
expected to be deprecated in the main branch. Therefore, in
preparation of merging this script with its main branch version,
install default settings for main branch's kata-opa service.
coco-default.rego blocks access to the same kata agent endpoints
that are blocked by agent-config.toml. For additional information,
search for "default-policy.rego" in main branch's rootfs.sh.
Fixes: #8219
Signed-off-by: Dan Mihai <dmihai@microsoft.com>
Bump version of image-rs and reqwest.
Build image-rs with the signature-simple-xrss feature flag.
Fixes: #8221
Signed-off-by: Matthew Arnold <mattarno@uk.ibm.com>
This is to define `SEALED_SECRET` as yes for a make target `cc-rootfs-initrd-tarball`,
which makes a service `confidential-data-hub` available with an initrd-based VM creation.
Fixes: #8210
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
kata-shim CCv0 does not propagate dynamically
updated k8s secret values due to incorrect
file name matching. This patch fixes the the wrong file
name matching for k8s secret volume paths.
Note that this problem has already fixed in the main
branch.
Fixes: #8208
Signed-off-by: Yohei Ueda <yohei@jp.ibm.com>
We're facing errors in the operator CI, which are related to the
measured rootfs.
For now, let's skip the cache builds (as those were dropped anyways for
this branch) and ensure we do a clean build, and then check if the
problem persists.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The guesthook config was missing which prevented handling
of GPUs with remote hypervisor
Fixes: #8172
Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
This is a patch that should **NOT** be forward ported to main, as there
we want to take a cleaner approach on configuring specific snapshotters
for specific runtime handlers.
However, for CC, for the v0.8.0 release of CC, this is good enough as it
is, and it'll allow us to set one snapshotter for all the deployments
done with the CoCo Operator.
This is the Kata Containers counterpart of the work, and there's still
work to be done on the Confidential Containers in order to make it work
as expected, as:
* Confidential Containers Operator has to expose to the users which
snapshotter will be configured
* Confidential Containers Opereator, specifically the pre-install hook,
will have to take care of actually installing and configuring the
snapshotter, so it can be used.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Fix setting the image service policy path when there
is a policy path in the agent config.
Fixes#8049
Signed-off-by: Matthew Arnold <mattarno@uk.ibm.com>
The name of the tarballs changed on main, but we didn't follow up
changing this on the CCv0 branch. :-/
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Fix the arch error when downloading the nydus tarball.
Signed-off-by: ChengyuZhu6 <chengyu.zhu@intel.com>
Signed-off-by: Steven Horsman <steven@uk.ibm.com>
(cherry picked from commit f6df3d6efb)
Guest rootfs will aligned to 128M, we may exceed the rootfs
with several megabytes but the rootfs will add 128M.
Fixes: #8009
Signed-off-by: Wang, Arron <arron.wang@intel.com>
As we'll need to test with both the vanilla and the forked versions of
containerd, let's make sure we'll specify both entries as part of our
versions.yaml file, and we can read whatever we need accordingly as part
of our tests jobs.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As we do not employ a forked containerd, we utilize the KataVirtualVolume
which storing the image url supplied by snapshotter as an integral part of `CreateContainer`.
Within this process, we store the image information in rootfs.storage and pass this image url through `CreateContainerRequest`.
This approach distinguishes itself from the use of `PullImageRequest`, as rootfs.storage is already set and initialized at this stage.
To maintain clarity and avoid any need for modification to the `OverlayfsHandler`,we introduce the `ImagePullHandler`.
This dedicated handler is responsible for orchestrating the image-pulling logic within the guest environment.
This logic encompasses tasks such as calling the image-rs to download and unpack the image into `/run/kata-containers/{container_id}/images`,
followed by a bind mount to `/run/kata-containers/{container_id}`.
Signed-off-by: ChengyuZhu6 <chengyu.zhu@intel.com>
Without using forked containerd, the kata-agent wouldn't receive the `PullImageRequest`.
To using nydus-snapshotter, kata-agent can pass the image url and container id to image-rs
to handle pulling image.So we need to redefine functions of pulling image in the guest to support
both PullImageRequest and remote snapshotter.
1) Extract codes for setting proxy environment variables into a separate function `set_proxy_env_vars`.
2) Create a separate function `handle_attestation_agent` to handle attestation agent
initialization.
3) Create a separate function `common_image_pull` for image pull logic.
4) Extract codes for unpacking pause image into a separate function `unpack_pause_image` and pass the necessary parameters to customize the behavior.
Fixes#7790
Signed-off-by: ChengyuZhu6 <chengyu.zhu@intel.com>
Co-authored-by: Jiang Liu <gerry@linux.alibaba.com>
Co-authored-by: Wang, Arron <arron.wang@intel.com>
Co-authored-by: wllenyj <wllenyj@linux.alibaba.com>
Co-authored-by: jordan9500 <jordan.jackson@ibm.com>
Co-authored-by: stevenhorsman <steven@uk.ibm.com>
