Include security options in the container created event

[timstclair]

New container creation events look like:

Created container with docker id /k8s_bar2.a4; Security:[seccomp=sub/subtest(md5:07c9bcb4db631f7ca191d6e0bca49f76)]

Created container with docker id /k8s_bar2.a4; Security:[seccomp=unconfined apparmor=foo-profile]

The goal is to provide enough information to confirm that the requseted security constraints were honored.

For #31284

/cc @dchen1107 @thockin @jfrazelle @pweil- @pmorie

---

Justification for v1.4:

• Risk: low. This appends some additional information to a human readable message. A bug here would probably not break any functionality
• Roll-back: I don't anticipate any more changes to this area of the code. No functionality depends on this change.
• Cost of not including: Users don't get any (positive) confirmation that the AppArmor or Seccomp profile they requested were actually enabled.

---

This change is

[dchen1107]

LGTM

[k8s-bot]

GCE e2e build/test passed for commit 785c83c.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[timstclair]

@k8s-bot node e2e test this, issue: #31633

[k8s-github-robot]

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

[k8s-bot]

GCE e2e build/test passed for commit 785c83c.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

Automatic merge from submit-queue

[smarterclayton]

I'm kind of confused why I, as a user, would care about this? It shows up in events for every user in the system - is it supposed to be actionable? What is it telling me that I need to know? The referenced issue doesn't actually clearly articulate why this message is important enough that everyone needs to see it.

[smarterclayton]

As a clarification - events are primarily to help users. I know this helps some users... it just doesn't help many of them. Maybe 2. Or 3. Can we move this somewhere more relevant, like very deeply buried in status where only someone who cares can see it?

[smarterclayton]

Or as an event annotation?

[timstclair]

Or as an event annotation?

I like that suggestion. Eventually this should be moved out to the monitoring pipeline anyway.