jhrozek
commented
3 years ago I think this would work well. I was thinking recently about the recording use-case for SELinux and I had a similar flow in mind. Some comments inline -- they mostly focus on the SELinux case, so hopefully I'm not hijacking the ticket too much.
What would you like to be added:
It should be possible to record profiles by using the log enricher, while preserving a good usability.
Why is this needed:
Right now the operator supports recording profiles by using the
ProfileRecordingCRD as well as the OCI seccomp BPF hook. This requires CRI-O as well as the hook to be pre-installed and configured on every node running the recording.However, the log enricher supports CRI-O and containerd as well as relies only on auditd. Adding recording support to the enricher may conflict with the existing recording feature and should seamless integrate into the operator. What we could do, is:
* Add a new field to the [`ProfileRecordingSpec`](https://github.com/kubernetes-sigs/security-profiles-operator/blob/d4ee3f9a931763072f1a7a89bc3ad448b5911ccf/api/profilerecording/v1alpha1/profilerecording_types.go#L30) to indicate that we either want to record by using the hook or by using the logs
I would suggest two pieces actually: what kind of profile is to be recorded and using what mechanism. The type could specify SELinux, seccomp (or in future apparmor?) or a combination. I wonder if the cleanest API might be to add an array of "Recorders", something like:
type ProfileRecordingSpec struct {
Kind ProfileRecordingKind `json:"kind"`
Recorder []ProfileRecorder // could be just a NamedObjectReference?
PodSelector metav1.LabelSelector `json:"podSelector"`
}and:
type ProfileRecorder struct {
ProfileKind string // seccomp, selinux, ...
RecorderKind string // audit, BPF, ...
}The recorders could be predefined by the operator (maybe based on what the platform supports) so that the user just links the profilerecording with the recorders and off they go.
* Based on the new field, a Recording CRD would have to ship with an [audit log profile](https://github.com/kubernetes-sigs/security-profiles-operator/blob/d4ee3f9a931763072f1a7a89bc3ad448b5911ccf/examples/seccompprofile.yaml#L11-L18)
Sorry, can you clarify? I understand that the workload under recording must be using a profile that has the defaultAction ACT_LOG, but I don't understand the point above. Isn't it enough to ensure that the audit profile exists before adding the profile as you say below?
* Reuse the existing recording webhook to add the audit log profile to the target pod (error if there is a profile already added by the user)
Ack
* Let the enricher take the recording profile into account to stream the syscalls to the GRPC server * Let the GRPC server collect the syscalls per container/pod until the recording gets deleted
I admit I haven't looked at the GRPC server or its usage that much, but on the surface this looks good.
* Reconcile a SeccompProfile CRD on recording deletion
This is probably my ignorance of how the GRPC server works, but would the recorder then fetch the syscalls from the server when the recording is deleted?
User story covered
As an infrastructure SRE, Kirsti wants to be able to easily correlate audit log entries related to security profiles to specific containers/pods. (link)
saschagrunert
What would you like to be added:
It should be possible to record profiles by using the log enricher, while preserving a good usability.
Why is this needed:
Right now the operator supports recording profiles by using the
ProfileRecordingCRD as well as the OCI seccomp BPF hook. This requires CRI-O as well as the hook to be pre-installed and configured on every node running the recording.However, the log enricher supports CRI-O and containerd as well as relies only on auditd. Adding recording support to the enricher may conflict with the existing recording feature and should seamless integrate into the operator. What we could do, is:
ProfileRecordingSpecto indicate that we either want to record by using the hook or by using the logsUser story covered