whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

revised to minumize usage of whitelist/blacklist

Browse Source
This commit is contained in:
Scott Stout
2020-06-09 14:14:52 -05:00
parent 352fafdcc7
commit e38b9dc9c6
8 changed files with 28 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/sysctl-cluster.md
+2 -2
View File
@@ -188,9 +188,9 @@ Do not configure these two fields such that there is overlap, meaning that a
given sysctl is both allowed and forbidden.
{{< warning >}}
If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
If you allow unsafe sysctls via the `allowedUnsafeSysctls` field
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
if the sysctl is not allowed via the `--allowed-unsafe-sysctls` kubelet
flag as well on that node.
{{< /warning >}}
content/en/docs/tasks/debug-application-cluster/audit.md
+1 -1
View File
@@ -245,7 +245,7 @@ Existing static backends that you configure with runtime flags are not affected
The AuditSink policy differs from the legacy audit runtime policy. This is because the API object serves different use cases. The policy will continue to evolve to serve more use cases.
The `level` field applies the given audit level to all requests. The `stages` field is now a whitelist of stages to record.
The `level` field applies the given audit level to all requests. The `stages` field is now a list of allowed stages to record.
#### Contacting the webhook