-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
container create: add inspect data to event #16599
Conversation
containers/common#1243 needs to merge first. |
As always, naming is the hardest part I guess. @containers/podman-maintainers PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: giuseppe, vrothberg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
We're going to absolutely murder the journal by doing this, but if it's what people want, I guess we have to deliver. LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO I think the store and backend for audit logs should be separately configurable and should not be mixed the regular logs.
I think in most cases people would like to dump audit logs to a cheaper storage and use it only when needed. https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/#log-backend
But is separate store even applicable in podman
do we have different events for audit ? Overall this is just an idea and not at all a blocker for this PR.
That was brought up but does not seem to matter.
The idea for a separate store is very interesting. For now, the goal is not have a holistic audit-logging (e.g., with including pulls, pushs, etc.) but to meet the use case. Adding the inspect data to the container-create event turned out to integrate well into already existing tooling for reading the journal while providing all possible data on which container is created with what image (digests etc.). |
Unrelated to this change |
Huh? We should investigate why, rootlessport should be as small as possible. I guess it is caused by c/common changes so not a blocker for this PR but I would like to take a look if I find some time. |
Likely caused by containers/common#1239 |
Gnah, will fix that in another PR. |
-> #16610 need this in first |
Ready for review/merge ✔️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
libpod/events.go
Outdated
return nil | ||
}() | ||
if err != nil { | ||
logrus.Errorf("Unable to add inspect data to container-create event: %v", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a customer who wants full audit data would prefer that container creation actually fail if we can't provide this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was contemplating it but couldn't decide. But you changed my mind. I also believe it's valid to fail in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Note that I was very careful not to change other callers to write events. Almost all are using defer
and changing that would be a (too) big PR.
I also took the occasion to rename PODMAN_CONTAINER_CREATE_INSPECT_DATA to PODMAN_CONTAINER_INSPECT_DATA ... just in case we want more container events to contain this data in the future.
When the new `events_container_create_inspect_data` option is enabled in containers.conf set the `ContainersInspectData` event field for each container-create event. The data was requested for the purpose of auditing (e.g., intrusion detection). Jira: https://issues.redhat.com/browse/RUN-1702 Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
/lgtm |
When the new
events_container_create_inspect_data
option is enabled incontainers.conf set the
ContainersCreateInspectData
event field foreach container-create event.
The data was requested for the purpose of auditing (e.g., intrusion detection).
Jira: https://issues.redhat.com/browse/RUN-1702
Signed-off-by: Valentin Rothberg vrothberg@redhat.com
Does this PR introduce a user-facing change?