Creating application security checklist

[AnshumanTripathi]

Creating an application security checklist.

Issue

kubernetes/sig-security#111

Deploy Preview

https://deploy-preview-46326--kubernetes-io-main-staging.netlify.app/docs/concepts/security/application-security-checklist/

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	86c48ee
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/66f9c132aeb1760008bcb862
😎 Deploy Preview	https://deploy-preview-46326--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[AnshumanTripathi]

@NissesSenap I have updated the checklist structure based on your recommendation.

Can you expand on

rbac, if you are using rbac in your http api, you are most likely doing something wrong. I would emphasize that really hard in the document.

I'm not sure what you mean here.

[NissesSenap]

@NissesSenap I have updated the checklist structure based on your recommendation.

Can you expand on

rbac, if you are using rbac in your http api, you are most likely doing something wrong. I would emphasize that really hard in the document.

I'm not sure what you mean here.

That is great @AnshumanTripathi , I will try to take a deeper look at the update as soon as possible. My point is that the majority of all apps ruining in Kubernetes don't need access to its API. So I would emphasize that custom rbac rules for apps just aren't needed, in the majority of applications. Still good to talk about it, just like you have, but point to that there are limited use cases for it.

[AnshumanTripathi]

@NissesSenap I have updated the checklist structure based on your recommendation.
Can you expand on

rbac, if you are using rbac in your http api, you are most likely doing something wrong. I would emphasize that really hard in the document.

I'm not sure what you mean here.

That is great @AnshumanTripathi , I will try to take a deeper look at the update as soon as possible. My point is that the majority of all apps ruining in Kubernetes don't need access to its API. So I would emphasize that custom rbac rules for apps just aren't needed, in the majority of applications. Still good to talk about it, just like you have, but point to that there are limited use cases for it.

Makes sense. I am not covering applications using Kubernetes client as a part of this checklist. I think having a doc about secure practices for applications that use the Kubernetes API (and operator) can be very helpful. I will create an issue for this :)

[AnshumanTripathi]

@NissesSenap created kubernetes/sig-security#121 for hardening guide for using Kubernetes API
Cross posted issue on k website - #47405

[tengqm]

I'd suggest we place this under content/en/docs/reference/security/, a new directory for consolidating security related contents. This page is not suitable for the concepts section.

[AnshumanTripathi]

I'd suggest we place this under content/en/docs/reference/security/, a new directory for consolidating security related contents. This page is not suitable for the concepts section.

Actually we can move this checklist and the existing checklist to content/en/docs/reference/issues-security maybe? I dont think I should do that as a part of this change though.

[tengqm]

I'd suggest we place this under content/en/docs/reference/security/, a new directory for consolidating security related contents. This page is not suitable for the concepts section.

Actually we can move this checklist and the existing checklist to content/en/docs/reference/issues-security maybe? I dont think I should do that as a part of this change though.

The issues-security directory is positioned to be a folder for disclosing the vulnerabilities of kubernetes release. What we are trying to compile is a collection of guidelines, best practices for users.

I don't think we want to kick this in and then follow up with another PR to move it.
We may want to get the page into a suitable folder in the first place.
The migration of other relevant pages could be left as follow-ups, for sure.

[AnshumanTripathi]

I'd suggest we place this under content/en/docs/reference/security/, a new directory for consolidating security related contents. This page is not suitable for the concepts section.

Actually we can move this checklist and the existing checklist to content/en/docs/reference/issues-security maybe? I dont think I should do that as a part of this change though.

The issues-security directory is positioned to be a folder for disclosing the vulnerabilities of kubernetes release. What we are trying to compile is a collection of guidelines, best practices for users.

I don't think we want to kick this in and then follow up with another PR to move it. We may want to get the page into a suitable folder in the first place. The migration of other relevant pages could be left as follow-ups, for sure.

Makes sense. I'll try to make that change

[sftim]

Thanks! We could really use this new page.

Here's some advice about how to get this ready to merge.

[tengqm]

This page, in its current format, with its current contents, doesn't belong to the concepts section. Please consider place it under the references section.

[reylejano]

I think this proposed "application security checklist" aligns with the live "security checklist" page which is aimed towards operators/cluster admins.
Since the "security checklist" page is currently under concepts, I'm ok to merge the "application security checklist" since under concepts

If we decide references is a better place then a PR can be made to move both of the "checklists" and possibly more like the
Authentication Mechanism Hardening Guide

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: reylejano

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:

• content/en/docs/OWNERS [reylejano]

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

[savitharaghunathan]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 36479c14b720d1addb2eb45e29c2988783bab833