[EPIC] Create "Securing Kubernetes and Knative" section for admin guide

[julz]

Describe the change you'd like to see

We should document in the admin guide how to set up Knative and Kubernetes securely (referencing up-stream guides as appropriate).

Topics might include (this is an initial brainstorm, and we should think carefully about which bits belong in our docs vs being better as references to upstream docs):

• Link to our threat model, to be clear about currently supported/unsupported use cases
• Link to our vulnerability reporting processes
• Namespace isolation considerations (e.g. suggested network policy)
• Protecting shared components
• Securing pods
  • "Out of the box" protections (e.g. minimal set of allowed volumes, subset of securityContext etc)
  • Description of relevant feature flags
  • Using PodSecurityPolicies and custom runtimes (e.g. Kata, gVisor)
  • Private registries

Additional context Add any other context or screenshots about the feature request here.

/assign @evankanderson for thoughts /assign @RichardJJG is there a template we should start from for this?

[RichardJJG]

Ideally all the docs would be made from the Procedure template because

• when people read docs they mostly just want to be told what to do and how to do it
• it's easier to write a good Procedure topic than a good Concept topic

The Concept template is necessary where you need to give a lot of context for procedures that would otherwise seem very alien. Beyond that you have to ask "does the reader really need to know this?" and, if they do, "how can I deliver this information as instructions for what the reader needs to do with it?"

[julz]

/assign

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[snneji]

@julz Do you still want to do this issue?

[julz]

Oops, no this isn't on my todo list at the moment, let me free it up for someone else

/unassign

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[evankanderson]

/remove-lifecycle stale

[evankanderson]

/accept

[evankanderson]

Should this doc go in the "Install" section?

[abrennan89]

@evankanderson it would depend on the doc. I think the idea was that this issue needs to be broken up into smaller issues depending on which docs are required. I don't think the docs WG really have the expertise to define what's required here in terms of doc deliverables. Maybe this issue can move to the security WG and ya'll can come back to us with smaller use cases / user stories and then we can advise on where specific procedures etc might fit into the docs?

[abrennan89]

Per the above comment, closing this issue as it has been open for over a year with no action. If there is docs work required from the docs WG, please open smaller issues with details of the required work. Otherwise I think this should be tracked / worked on in the Security WG instead.

[evankanderson]

Reopening as work for the security WG, not the docs WG.