WorkloadAttestor(k8s): Inconsistent attestation with 1-hash-to-many-tags

[rturner3]

Originally reported by @nweedon-u:

• Version: 1.3.x - 1.6.x (could also be earlier, untested in 1.7.x)
• Platform: Linux
• Subsystem: k8s workload attestor

I was investigating why a Kubernetes pod approved with k8s:pod-image:: was failing to attest on some Kubernetes workers and not others. Sample log from the app: Failed to watch the Workload API: rpc error: code = PermissionDenied desc = no identity issued.

It turns out that the Kubernetes workload attestor can incorrectly attest pods if two or more docker images are downloaded to a node which share the same container hash - this can be observed by turning on debug-level logging on the affected spire-agent.

Reproduction steps:

1. Entry added to spire-server with k8s:pod-image:/image:tag-a selector
2. Push image to registry with two tags (for example, tag-a and tag-b).
3. Start a pod with tag-a. It should start properly.
4. Start a pod with tag-b on the same node. It will not attest correctly as spire-agent will attest the container with tag-a.

Workaround steps:

This can be worked around by using pod-image with a SHA-256 hash, for example with a docker runtime:docker-pullable://@sha256:.

[rturner3]

The CRI API used by the kubelet to fetch a container's image is not specific about which image name to include in its API responses in the case where a single image SHA is associated with multiple tags. In some CRI implementations (e.g. docker, https://github.com/Mirantis/cri-dockerd/issues/165), it has been observed that the image name returned by the API can be inconsistent in this case.

Due to the lack of standardization around how this case should be handled in the CRI API, we should add a note in the k8s WorkloadAttestor plugin documentation about the limitations of the pod-image/pod-init-image/container-image selectors and mention the tradeoff between human readability/ease of use vs. uniqueness for relying on image names vs. image IDs for workload registration entries.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[azdagron]

Still relevant.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[Moon1706]

Wow, it's still relevant. Fix pls, version 1.8.3