-
Notifications
You must be signed in to change notification settings - Fork 893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect event values for container.image.* when using image digests #1187
Comments
Thanks for reporting @plasticine ! I'll try to investigate this. |
Hey there @fntlnz — just wanted to check in and see if you managed to uncover anything here? We’re still seeing this issue, though I’ll try with the recently released |
Hi @plasticine Thanks for the detailed issue! - @leodido and I debugged this for quite some time on GKE After Falco is deployed and running, we deployed the event generator as it follows:
Here is a sample of some events we had:
Can you give us more details on how the pods are deployed? If you can try our |
Also, in our debugging session, we have containerd version:
Could you report the version you have in you setup? |
Maybe this helps to pin-point things further, I'm seeing the same as @plasticine without BPF enabled on my env (falco 0.23.0): |
Hrm! 🤔 Hoping to get some time to circle back on this next week and see if I can get a more detailed repo
… On 29 May 2020, at 10:37 pm, Daniel Pittner ***@***.***> wrote:
Maybe this helps to pin-point things further, I'm seeing the same as @plasticine without BPF enabled on my env (falco 0.23.0):
{
"machine": "x86_64",
"nodename": "falco-2jd7j",
"release": "4.4.0-177-generic",
"sysname": "Linux",
"version": "#207-Ubuntu SMP Mon Mar 16 01:16:10 UTC 2020"
}
it's an IBM Cloud IKS 1.15
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Issues labeled "cncf", "roadmap" and "help wanted" will not be automatically closed. Please refer to a maintainer to get such label added if you think this should be kept open. |
@fntlnz: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Oh no i didn't want to close this! /reopen |
@fntlnz: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@fntlnz Sorry 🙈 I’ve been meaning to try and get back to this for ages, I’ll try and make time this week! I’ve been wondering if there is something about our gke k8s that is tripping things up; it’s a stretch, but I’m wondering if binary auth is possibly in the mix, as that’s something we leverage heavily. |
Thanks @plasticine - no need to be sorry, time flies! Thanks for your help! |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Issues labeled "cncf", "roadmap" and "help wanted" will not be automatically closed. Please refer to a maintainer to get such label added if you think this should be kept open. |
Is this problem still present in Falco 0.25.0 ? |
Looks like this issue still exists on 0.26.2, just tested it now with the exact configuration that @plasticine has. |
Are there any specific things I can provide to make debugging this easier? From our configuration that is. |
@plasticine and I have a suspicion that this is related to having binary authorization enabled on our GKE clusters. @fntlnz was binary auth enabled when you tested this with your GKE configuration? |
Could you share the detailed steps to reproduce the problem? Thanks in advance! |
@leogr We literally just create a new GKE cluster now running 1.17 with Binary authorization enabled and then deploy the falco workload. You should then be able to replicate the issue as per the original post. |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh with Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue with Mark the issue as fresh with Provide feedback via https://github.com/falcosecurity/community. |
@poiana: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I'm also seeing this behavior on Azure AKS v1.19.7 however I've seen this only from the Nginx Ingress Controller so far. Other containers seems to work fine and output the I tried to create a reproducable scenario on minikube but was unable to. It worked fine. Falco info
Node info
Example alert
Nginx Ingress Controller deployed like so
|
/reopen |
@ejderdal: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The issue seems to be still present: https://kubernetes.slack.com/archives/CMWH3EH32/p1681661535622169 |
Hi @plasticine 👋 We patched the container engine in this regard a bit here https://github.com/falcosecurity/libs/pull/771/files. Also sometimes see |
Some of our images also uses the format |
Amazing ty will start looking into it next week after KubeCon and will ping you on slack as well 🙏 ! |
@sigurdfalk tagged you in the PR. Added backup lookups ... after that I wouldn't know where else to extract the image from, searched the entire container status response. It certainly isn't a Falco bug, sometimes it simply just is |
Rotten issues close after 30d of inactivity. Reopen the issue with Mark the issue as fresh with Provide feedback via https://github.com/falcosecurity/community. |
@poiana: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Yep@ melissa fixed that if i remember correctly! |
Correct, @gnosek PR had the biggest impact (falcosecurity/libs#771), but to increase robustness even more I added backup lookups (falcosecurity/libs#1067) for the Kubernetes cases (cri, containerd and cri-o). In summary we now try to look up the container image from all possible places in the container status response, especially for the Kubernetes use case. We can mark this as completed for 0.35.0 and should there still be issues, we can continue working on it. |
/milestone 0.35.0 |
Hey there — thanks very much for Falco, it’s an amazing bit of software! 👋
So, we almost exclusively deploy all our images by sha256 digest, as opposed to by tag, and when attempting to update Falco from
0.17.0
to0.22.1
on a bunch of our k8s clusters we’ve observed that events all seem to have the followingcontainer.image.repository
, andcontainer.image.tag
values;How to reproduce it
I’ve validated this behavior on GKE nodes running
1.15.x
on top of COS with Containerd, and have re-deployed our falco install from scratch using https://github.com/falcosecurity/falco/tree/master/integrations/k8s-using-daemonset/k8s-with-rbacExpected behaviour
I would expect that the
repository
field would contain the actual image repository, and thetag
field either the tag, or digest....or maybe even better, a new field
digest
in the event thattag
is null and the image is being referenced by digest;Environment
GKE, running
1.15.x
on COS with Containerdhttps://github.com/falcosecurity/falco/tree/master/integrations/k8s-using-daemonset/k8s-with-rbac
The text was updated successfully, but these errors were encountered: