You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/concepts/security/application-security-checklist.md
+70-33Lines changed: 70 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,94 +8,131 @@ weight: 110
8
8
9
9
<!-- overview -->
10
10
11
-
This checklist aims on providing basic guidelines on securing applications running in Kubernetes from a developer perspective.
12
-
This list is not meant to be exhaustive and is meant to evolve over time.
11
+
This checklist aims to provide basic guidelines on securing applications
12
+
running in Kubernetes from a developer's perspective.
13
+
This list is not meant to be exhaustive and is intended to evolve over time.
13
14
14
15
<!-- The following is taken from the existing checklist created for Kubernetes admins. https://kubernetes.io/docs/concepts/security/security-checklist/ -->
15
16
16
17
On how to read and use this document:
17
18
18
19
- The order of topics does not reflect an order of priority.
19
20
- Some checklist items are detailed in the paragraph below the list of each section.
20
-
- This checklist assumes a `developer` is a Kubernetes cluster user that interacts with namespaced scope objects.
21
-
21
+
- This checklist assumes that a `developer` is a Kubernetes cluster user who
22
+
interacts with namespaced scope objects.
22
23
23
24
{{< caution >}}
24
-
Checklists are **not** sufficient for attaining a good security posture on their own. A good security posture requires constant attention and improvement, but a checklist can be the first step on the never-ending journey towards security preparedness. Some of the recommendations in this checklist may be too restrictive or too lax for your specific security needs. Since Kubernetes security is not "one size fits all", each category of checklist items should be evaluated on its merits.
25
+
Checklists are **not** sufficient for attaining a good security posture on their own.
26
+
A good security posture requires constant attention and improvement, but a checklist
27
+
can be the first step on the never-ending journey towards security preparedness.
28
+
Some recommendations in this checklist may be too restrictive or too lax for
29
+
your specific security needs. Since Kubernetes security is not "one size fits all",
30
+
each category of checklist items should be evaluated on its merits.
25
31
{{< /caution >}}
26
32
27
-
28
33
<!-- body -->
34
+
29
35
## Base security hardening
30
-
The following checklist provide a base security hardening recommendations that would apply to most applications deploying to Kubernetes.
36
+
37
+
The following checklist provides base security hardening recommendations that
38
+
would apply to most applications deploying to Kubernetes.
31
39
32
40
### Application design
33
41
34
-
-[ ] Following the right [security principles](https://www.cncf.io/wp-content/uploads/2022/06/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) when designing applicaitons.
35
-
-[ ] Application configured with appropriate {{< glossary_tooltip text="QoS class" term_id="QoS-class" >}} through resource request and limits
-[ ] Configure the container to execute as a less privileged user (for example, using `runAsUser` and `runAsGroup`), and configure appropriate permissions on files or directories inside the container image.
60
+
-[ ] Configure the container to execute as a less privileged user
61
+
(for example, using `runAsUser` and `runAsGroup`), and configure appropriate
62
+
permissions on files or directories inside the container image.
48
63
-[ ] Optionally add a supplementary group with `fsGroup` to access persistent volumes.
49
-
-[ ] The application deploys into a namespace that enforces an appropriate [Pod security standard](/docs/concepts/security/pod-security-standards/). If you cannot control this enforcement for the cluster(s) where the application is deployed, take this into account either through documentation or additional defense in depth.
64
+
-[ ] The application deploys into a namespace that enforces an appropriate
-[ ] Drop all capabilities from the containers, and add back only specific ones that are needed for operation of the container.
74
+
-[ ] Drop all capabilities from the containers and add back only specific ones
75
+
that are needed for operation of the container.
57
76
58
77
### Role Based Access Control (RBAC) {#rbac}
59
78
60
-
-[ ] Permissions such as **create**, **patch**, **update** and **delete** should be only granted if necessary.
61
-
-[ ] Avoid creating RBAC permissions to create or update roles which can lead to [privilege escalation](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping).
62
-
-[ ] Review bindings for the `system:unauthenticated` group and remove them where possible, as this gives access to anyone who can contact the API server at a network level.
79
+
-[ ] Permissions such as **create**, **patch**, **update** and **delete**
80
+
should be only granted if necessary.
81
+
-[ ] Avoid creating RBAC permissions to create or update roles which can lead to
-[ ] Review bindings for the `system:unauthenticated` group and remove them where
84
+
possible, as this gives access to anyone who can contact the API server at a network level.
63
85
64
-
The **create**, **update** and **delete** verbs should be permitted judiciously. The **patch** verb if allowed on a Namespace can
65
-
[allow users to update labels on the namespace or deployments](/docs/concepts/security/rbac-good-practices/#namespace-modification) which can increase the attack surface.
86
+
The **create**, **update** and **delete** verbs should be permitted judiciously.
87
+
The **patch** verb if allowed on a Namespace can
88
+
[allow users to update labels on the namespace or deployments](/docs/concepts/security/rbac-good-practices/#namespace-modification)
89
+
which can increase the attack surface.
66
90
67
-
For sensitive workloads, consider providing a recommended ValidatingAdmissionPolicy that further restricts the permitted write actions.
91
+
For sensitive workloads, consider providing a recommended ValidatingAdmissionPolicy
92
+
that further restricts the permitted write actions.
68
93
69
94
### Image security
70
95
71
-
-[ ] Using a image scanning tool the scan an image before deploying containers in the Kubernetes cluster.
96
+
-[ ] Using an image scanning tool to scan an image before deploying containers in the Kubernetes cluster.
72
97
-[ ] Use container signing to validate the container image signature before deploying to the Kubernetes cluster.
73
98
74
-
### Network Policies
99
+
### Network policies
75
100
76
-
-[ ] Configure [NetworkPolicies](/docs/concepts/services-networking/network-policies/) to only allow expected ingress and egress traffic from the pods.
to only allow expected ingress and egress traffic from the pods.
77
103
78
-
Make sure that your cluster provides and enforces NetworkPolicy. If you are writing an application that people will deploy to different clusters, consider whether you can assume that NetworkPolicy is available and enforced.
104
+
Make sure that your cluster provides and enforces NetworkPolicy.
105
+
If you are writing an application that users will deploy to different clusters,
106
+
consider whether you can assume that NetworkPolicy is available and enforced.
79
107
80
108
## Advanced security hardening {#advanced}
81
109
82
-
This section of this guide covers some advanced security hardening points which might be valuable based on different Kubernetes environment setup
110
+
This section of this guide covers some advanced security hardening points
111
+
which might be valuable based on different Kubernetes environment setup.
83
112
84
113
### Linux container security
85
114
86
-
Configure {{< glossary_tooltip text="Security Context" term_id="Security-Context" >}} for the pod-container.
-[ ][Set the Seccomp Profile for a Container](/docs/tasks/configure-pod-container/security-context/#set-the-seccomp-profile-for-a-container).
119
+
-[ ][Restrict a Container's Access to Resources with AppArmor](/docs/tutorials/security/apparmor/).
120
+
-[ ][Assign SELinux Labels to a Container](/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container).
90
121
91
-
### Runtime Classes
122
+
### Runtime classes
92
123
93
124
-[ ] Configure appropriate runtime classes for containers.
94
125
95
126
{{% thirdparty-content %}}
96
127
97
-
Some containers may require a different isolation level from what is provided by the default runtime of the cluster. `runtimeClassname` can be used in a podspec to define a differnt runtime class.
128
+
Some containers may require a different isolation level from what is provided by
129
+
the default runtime of the cluster. `runtimeClassName` can be used in a podspec
130
+
to define a different runtime class.
98
131
99
-
For sensitive workloads consider using kernel emulation tools like [gVisor](https://gvisor.dev/docs/), or virtualized isolation using a mechanism such as [kata-containers](https://katacontainers.io/).
132
+
For sensitive workloads consider using kernel emulation tools like
133
+
[gVisor](https://gvisor.dev/docs/), or virtualized isolation using a mechanism
134
+
such as [kata-containers](https://katacontainers.io/).
100
135
101
-
In high trust environments, consider using [confidential virtual machines](/blog/2023/07/06/confidential-kubernetes/) to improve cluster security even further.
0 commit comments