Merge pull request #21591 from scottstout/master
Changed whitelist to allowlist and blacklist to denylist.
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
29f3c2858c
|
|
@ -34,7 +34,7 @@ administrator to control the following:
|
|||
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
|
||||
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
|
||||
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
|
||||
| White list of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
|
||||
| Allow specific FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
|
||||
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
|
||||
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
|
||||
| The user and group IDs of the container | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) |
|
||||
|
|
@ -401,13 +401,13 @@ namespace. Doing so gives the pod access to the loopback device, services
|
|||
listening on localhost, and could be used to snoop on network activity of other
|
||||
pods on the same node.
|
||||
|
||||
**HostPorts** - Provides a whitelist of ranges of allowable ports in the host
|
||||
**HostPorts** - Provides a list of ranges of allowable ports in the host
|
||||
network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive)
|
||||
and `max`(inclusive). Defaults to no allowed host ports.
|
||||
|
||||
### Volumes and file systems
|
||||
|
||||
**Volumes** - Provides a whitelist of allowed volume types. The allowable values
|
||||
**Volumes** - Provides a list of allowed volume types. The allowable values
|
||||
correspond to the volume sources that are defined when creating a volume. For
|
||||
the complete list of volume types, see [Types of
|
||||
Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*`
|
||||
|
|
@ -438,7 +438,7 @@ minimum value of the first range as the default. Validates against all ranges.
|
|||
all ranges if `FSGroups` is set.
|
||||
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
|
||||
|
||||
**AllowedHostPaths** - This specifies a whitelist of host paths that are allowed
|
||||
**AllowedHostPaths** - This specifies a list of host paths that are allowed
|
||||
to be used by hostPath volumes. An empty list means there is no restriction on
|
||||
host paths used. This is defined as a list of objects with a single `pathPrefix`
|
||||
field, which allows hostPath volumes to mount a path that begins with an
|
||||
|
|
@ -469,7 +469,7 @@ root filesystem (i.e. no writable layer).
|
|||
|
||||
### FlexVolume drivers
|
||||
|
||||
This specifies a whitelist of FlexVolume drivers that are allowed to be used
|
||||
This specifies a list of FlexVolume drivers that are allowed to be used
|
||||
by flexvolume. An empty list or nil means there is no restriction on the drivers.
|
||||
Please make sure [`volumes`](#volumes-and-file-systems) field contains the
|
||||
`flexVolume` volume type; no FlexVolume driver is allowed otherwise.
|
||||
|
|
@ -555,7 +555,7 @@ the PodSecurityPolicy. For more details on Linux capabilities, see
|
|||
The following fields take a list of capabilities, specified as the capability
|
||||
name in ALL_CAPS without the `CAP_` prefix.
|
||||
|
||||
**AllowedCapabilities** - Provides a whitelist of capabilities that may be added
|
||||
**AllowedCapabilities** - Provides a list of capabilities that are allowed to be added
|
||||
to a container. The default set of capabilities are implicitly allowed. The
|
||||
empty set means that no additional capabilities may be added beyond the default
|
||||
set. `*` can be used to allow all capabilities.
|
||||
|
|
@ -579,7 +579,7 @@ specified.
|
|||
|
||||
### AllowedProcMountTypes
|
||||
|
||||
`allowedProcMountTypes` is a whitelist of allowed ProcMountTypes.
|
||||
`allowedProcMountTypes` is a list of allowed ProcMountTypes.
|
||||
Empty or nil indicates that only the `DefaultProcMountType` may be used.
|
||||
|
||||
`DefaultProcMount` uses the container runtime defaults for readonly and masked
|
||||
|
|
|
|||
|
|
@ -43,9 +43,9 @@ should range from highly restricted to highly flexible:
|
|||
The Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically
|
||||
aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
|
||||
|
||||
The privileged policy is defined by an absence of restrictions. For blacklist-oriented enforcement
|
||||
The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
|
||||
mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
|
||||
rather than an instantiated policy. In contrast, for a whitelist oriented mechanism (such as Pod
|
||||
rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
|
||||
Security Policy) the privileged policy should enable all controls (disable all restrictions).
|
||||
|
||||
### Baseline/Default
|
||||
|
|
@ -90,7 +90,7 @@ enforced/disallowed:
|
|||
<br><b>Restricted Fields:</b><br>
|
||||
spec.containers[*].securityContext.capabilities.add<br>
|
||||
spec.initContainers[*].securityContext.capabilities.add<br>
|
||||
<br><b>Allowed Values:</b> empty (optionally whitelisted defaults)<br>
|
||||
<br><b>Allowed Values:</b> empty (or restricted to a known list)<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -105,17 +105,17 @@ enforced/disallowed:
|
|||
<tr>
|
||||
<td>Host Ports</td>
|
||||
<td>
|
||||
HostPorts should be disallowed, or at minimum restricted to a whitelist.<br>
|
||||
HostPorts should be disallowed, or at minimum restricted to a known list.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.containers[*].ports[*].hostPort<br>
|
||||
spec.initContainers[*].ports[*].hostPort<br>
|
||||
<br><b>Allowed Values:</b> 0, undefined, (whitelisted)<br>
|
||||
<br><b>Allowed Values:</b> 0, undefined (or restricted to a known list)<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>AppArmor <em>(optional)</em></td>
|
||||
<td>
|
||||
On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to a whitelisted set of profiles.<br>
|
||||
On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
|
||||
<br><b>Allowed Values:</b> 'runtime/default', undefined<br>
|
||||
|
|
@ -145,7 +145,7 @@ enforced/disallowed:
|
|||
<tr>
|
||||
<td>Sysctls</td>
|
||||
<td>
|
||||
Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for a whitelisted "safe" subset.
|
||||
Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset.
|
||||
A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.securityContext.sysctls<br>
|
||||
|
|
@ -249,7 +249,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
|
|||
<tr>
|
||||
<td>Seccomp</td>
|
||||
<td>
|
||||
The 'runtime/default' seccomp profile must be required, or allow additional whitelisted values.<br>
|
||||
The 'runtime/default' seccomp profile must be required, or allow specific additional profiles.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
metadata.annotations['seccomp.security.alpha.kubernetes.io/pod']<br>
|
||||
metadata.annotations['container.seccomp.security.alpha.kubernetes.io/*']<br>
|
||||
|
|
|
|||
|
|
@ -89,9 +89,9 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g
|
|||
|
||||
__policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules.
|
||||
|
||||
__ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
|
||||
__ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
|
||||
|
||||
__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
|
||||
__egress__: Each NetworkPolicy may include a list of allowed `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
|
||||
|
||||
So, the example NetworkPolicy:
|
||||
|
||||
|
|
|
|||
|
|
@ -612,7 +612,7 @@ node selector.
|
|||
2. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector`
|
||||
plugin configuration file as the node selector.
|
||||
3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection.
|
||||
4. Evaluate the pod's node selector against the namespace-specific whitelist defined the plugin configuration file.
|
||||
4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the plugin configuration file.
|
||||
Conflicts result in rejection.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -674,15 +674,15 @@ for more information.
|
|||
The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace.
|
||||
It rejects the pod request if there is a conflict.
|
||||
It then merges the tolerations annotated on the namespace into the tolerations of the pod.
|
||||
The resulting tolerations are checked against a whitelist of tolerations annotated to the namespace.
|
||||
The resulting tolerations are checked against a list of allowed tolerations annotated to the namespace.
|
||||
If the check succeeds, the pod request is admitted otherwise it is rejected.
|
||||
|
||||
If the namespace of the pod does not have any associated default tolerations or a whitelist of
|
||||
tolerations annotated, the cluster-level default tolerations or cluster-level whitelist of tolerations are used
|
||||
If the namespace of the pod does not have any associated default tolerations or allowed
|
||||
tolerations annotated, the cluster-level default tolerations or cluster-level list of allowed tolerations are used
|
||||
instead if they are specified.
|
||||
|
||||
Tolerations to a namespace are assigned via the `scheduler.alpha.kubernetes.io/defaultTolerations` annotation key.
|
||||
The whitelist can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
|
||||
The list of allowed tolerations can be added via the `scheduler.alpha.kubernetes.io/tolerationsWhitelist` annotation key.
|
||||
|
||||
Example for namespace annotations:
|
||||
|
||||
|
|
|
|||
|
|
@ -495,10 +495,10 @@ and `scp` using that other user instead.
|
|||
|
||||
The `admin.conf` file gives the user _superuser_ privileges over the cluster.
|
||||
This file should be used sparingly. For normal users, it's recommended to
|
||||
generate an unique credential to which you whitelist privileges. You can do
|
||||
generate an unique credential to which you grant privileges. You can do
|
||||
this with the `kubeadm alpha kubeconfig user --client-name <CN>`
|
||||
command. That command will print out a KubeConfig file to STDOUT which you
|
||||
should save to a file and distribute to your user. After that, whitelist
|
||||
should save to a file and distribute to your user. After that, grant
|
||||
privileges by using `kubectl create (cluster)rolebinding`.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -189,9 +189,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 >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ content_type: tutorial
|
|||
AppArmor is a Linux kernel security module that supplements the standard Linux user and group based
|
||||
permissions to confine programs to a limited set of resources. AppArmor can be configured for any
|
||||
application to reduce its potential attack surface and provide greater in-depth defense. It is
|
||||
configured through profiles tuned to whitelist the access needed by a specific program or container,
|
||||
configured through profiles tuned to allow the access needed by a specific program or container,
|
||||
such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either
|
||||
*enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports
|
||||
violations.
|
||||
|
|
|
|||
Loading…
Reference in New Issue