Creating application security checklist

[AnshumanTripathi]

trafficstars

Creating an application security checklist.

Issue

https://github.com/kubernetes/sig-security/issues/111

Deploy Preview

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

[netlify[bot]]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	86c48ee42d6c1ce8015ff395f335593b47ca4aca
🔍 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.

[sftim]

/remove-area blog localization web-development release-eng

[sftim]

/remove-language bn /remove-language de /remove-language es /remove-language fr /remove-language hi /remove-language id /remove-language it /remove-language ja /remove-language ko /remove-language pl /remove-language pt /remove-language ru /remove-language uk /remove-language vi /remove-language zh

[sftim]

/remove-sig release /sig security

[mtardy]

This looks good :)! I think it's a very valuable checklist for app developers.

[AnshumanTripathi]

First of all, great job, I think this document is a great addition.

But here are my thoughts. First, my question is, for whom is this document written for? Is it the 85-90% of app developers that run an http API or an event based app in a non-critical environment that just wants a good base layer? Or are we trying to point to all security features that exist from an app developer point of view?

Personally, I think we should aim this document mainly towards the 85-90% of the users. Especially since there is a tendency to want to be able to complete everything on a checklist, but if it becomes too painful, you end up doing nothing. See keep it relatively simple and provide some kind of leveling system.

I would add a header called ## base security. In there I would add the most basic stuff.

Then I would add another header, ## advanced security, or something like that.

I would keep everything you have written, but I would move these down to advanced security

• 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.
• runtime class, custom runetime classes isn't something that the majority of Kubenetes environment will use.
• Seccomp profiles, It's more or less impossible to setup unless you have some kind of tooling + since version 1.25 the default profile is enabled by default.
• SElinux, most developers don't know what it is and just like secomp profile you more or less need tooling to create something decent.
• AppArmor, even fewer people know what it is, and you need custom tooling to create something more advanced than default.

Thanks for the detailed response. I like this format and I will try to update the document accordingly. Regarding the target audience I did add this point

This checklist assumes a developer is a Kubernetes cluster user that interacts with namespaced scope objects. https://github.com/kubernetes/website/pull/46326/files#diff-5285725b7ae5cc6b415f12dbb2acf91aea311bf5dd5dc71851b29c216afcb9adR20

I did realize that identifying the target audience is key here and then keeping the list generic so that it can be used by everyone. Because app developers can consist of tools that can be running cluster wide like log and metric collectors or policy agents. This is where the line between admins and developers start to blur. I'll try to add more details about the target audience for this list.

[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 https://github.com/kubernetes/sig-security/issues/121 for hardening guide for using Kubernetes API Cross posted issue on k website - https://github.com/kubernetes/website/issues/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

[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