recording: Emit event when attempting to record a privileged container + add docs

[jhrozek]

What type of PR is this?

/kind cleanup
/kind documentation

What this PR does / why we need it:

• docs: Document that the log based recorder can't record privileged pods - adds docs that make it clear that we can't record privileged containers using the log enricher
• recording: Issue an event if a privileged pod is recorded with a log-based recorder - when log enricher is used to record privileged containers, attach an event to the recording object

Which issue(s) this PR fixes:

None

Does this PR have test?

No

Special notes for your reviewer:

N/A

Does this PR introduce a user-facing change?

If the log-based recorder is in use and the user attempts to either record a container which already had its SecurityContext set or attempts to record a privileged container (which ignores both seccomp profiles and selinux contexts), the profile recording webhook issues a warning event.

[JAORMX]

/lgtm cancel
@jhrozek This is actually a user facing change, so this should have a relevant release note.

[saschagrunert]

Do we wanna behave in the same way if we already have a seccomp profile applied to the container?

[JAORMX]

I think there might be a use-case for still recording a workload even if there's a profile applied to it. e.g. verifying that the applied profile is sufficient.

[saschagrunert]

But for the log enricher we would override the existing profile.

[JAORMX]

For Seccomp? I thought it was only the case for SELinux.

[jhrozek]

Do we wanna behave in the same way if we already have a seccomp profile applied to the container?

I'm sorry, can you elaborate? Are you thinking about the case where someone records a workload while already specifying the profile in the first place?

[saschagrunert]

The webhook just updates the security context for log based seccomp profile recordings:

security-profiles-operator/internal/pkg/webhooks/recording/recording.go

Lines 250 to 268 in 1e4dfea

	func (p *podSeccompRecorder) updateSeccompSecurityContext(
	ctr *corev1.Container,
	) {
	if ctr.SecurityContext == nil {
	ctr.SecurityContext = &corev1.SecurityContext{}
	}
	if ctr.SecurityContext.SeccompProfile == nil {
	ctr.SecurityContext.SeccompProfile = &corev1.SeccompProfile{}
	}
	ctr.SecurityContext.SeccompProfile.Type = corev1.SeccompProfileTypeLocalhost
	profile := fmt.Sprintf(
	"operator/%s/%s.json",
	p.impl.GetOperatorNamespace(),
	config.LogEnricherProfile,
	)
	ctr.SecurityContext.SeccompProfile.LocalhostProfile = &profile
	}

[saschagrunert]

Do we wanna behave in the same way if we already have a seccomp profile applied to the container?

I'm sorry, can you elaborate? Are you thinking about the case where someone records a workload while already specifying the profile in the first place?

Yes, exactly. We could assume that users do not understand how it works in detail, so I'm wondering if we wanna make them aware that we overwrote their already used seccomp profile.

[jhrozek]

OK, makes sense. btw it seems like we were overwriting the context for SELinux recording as well, so I added events to both.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JAORMX, jhrozek, saschagrunert

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:

• OWNERS [JAORMX,jhrozek,saschagrunert]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment