aquasecurity/tracee

Image digest not being reported

Closed this issue · 2 comments

Description

When running tracee in a Kubernetes environment (x86_64 hosts), the image digest is populated with the image name rather than the digest. See below:

{"timestamp":1724096382292763343,"threadStartTime":1721136093296949337,"processorId":1,"processId":1,"cgroupId":5357,"threadId":14,"parentProcessId":0,"hostProcessId":2498,"hostThreadId":9355,"hostParentProcessId":2337,"userId":65532,"mountNamespace":4026532366,"pidNamespace":4026532367,"processName":"coredns","executable":{"path":""},"hostName":"coredns-586b798","containerId":"b59cf637ad37babd36030dd4a29459c87f2c9cb1ba79988dea4056413a5f197e","container":{"id":"b59cf637ad37babd36030dd4a29459c87f2c9cb1ba79988dea4056413a5f197e","name":"coredns","image":"602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.11.1-eksbuild.8","imageDigest":"602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.11.1-eksbuild.8"},"kubernetes":{"podName":"coredns-586b798467-mnl68","podNamespace":"kube-system","podUID":"86bce450-b547-4eaa-89a6-ad09a2496288"},"eventId":"735","eventName":"security_socket_connect","matchedPolicies":[""],"argsNum":3,"returnValue":0,"syscall":"connect","stackAddresses":null,"contextFlags":{"containerStarted":true,"isCompat":false},"threadEntityId":276259053,"processEntityId":2252297612,"parentEntityId":609156090,"args":[{"name":"sockfd","type":"int","value":10},{"name":"type","type":"int","value":1},{"name":"remote_addr","type":"struct sockaddr*","value":{"sa_family":"AF_INET","sin_addr":"0.0.0.0","sin_port":"8080"}}]}

Output of tracee version:

Tracee version "v0.21.0"

Output of uname -a:

Linux tracee-t59gw 6.1.94-99.176.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Jun 18 14:57:56 UTC 2024 x86_64 GNU/Linux

Additional details

There seems to be a typo here:

if len(imageInfo.Image.RepoDigests) > 0 {
imageDigest = imageInfo.Image.RepoTags[0]
}

I believe it should read:

				if len(imageInfo.Image.RepoDigests) > 0 {
					imageDigest = imageInfo.Image.RepoDigests[0]
				}

@jeason81 thanks for reporting us. @NDStrahilevitz could you check this later?

If it helps, I'm deploying in an EKS cluster using the amzn2-ami-minimal-hvm-2.0.20240719.0-x86_64-ebs AMI. Here are the details:

Kubernetes 1.30

AMI Names Release version Included artifacts
amazon-eks-node-al2023-x86_64-standard-1.30-v20240807 1.30.2-20240807 s3://amazon-eks/1.30.2/2024-07-12/
amazon-eks-node-1.30-v20240807 1.30.2-20240807 s3://amazon-eks/1.30.2/2024-07-12/
amazon-eks-node-al2023-arm64-standard-1.30-v20240807 1.30.2-20240807 s3://amazon-eks/1.30.2/2024-07-12/
amazon-eks-arm64-node-1.30-v20240807 1.30.2-20240807 s3://amazon-eks/1.30.2/2024-07-12/
amazon-eks-gpu-node-1.30-v20240807 1.30.2-20240807 s3://amazon-eks/1.30.2/2024-07-12/
Package AL2_x86_64
amazon-ssm-agent 3.3.380.0-1.amzn2
containerd 1.7.11-1.amzn2.0.1
cuda-12-2
efa
kernel 5.10.220-209.869.amzn2
nvidia-driver-latest-dkms
runc 1.1.11-1.amzn2
Package AL2023_x86_64_STANDARD
amazon-ssm-agent 3.3.380.0-1.amzn2023
containerd 1.7.20-1.amzn2023.0.1
kernel 6.1.102-108.177.amzn2023
runc 1.1.11-1.amzn2023.0.1