-
Notifications
You must be signed in to change notification settings - Fork 686
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defined notes and rules for BSI APP.4.4.A18 #12154
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
--- | ||
default_result: MANUAL |
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,43 @@ | ||||||
documentation_complete: true | ||||||
|
||||||
title: 'Ensure appropriate Network Policies are configured' | ||||||
|
||||||
description: |- | ||||||
Configure Network Policies in any application namespace in an approrpriate way, so that | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
only the required communications are allowed. The Network Policies should precisely define | ||||||
source and target using label selectors and ports. | ||||||
rationale: |- | ||||||
By default, all pod to pod traffic within a cluster is allowed. Network | ||||||
Policy creates a pod- level firewall that can be used to restrict traffic | ||||||
between sources. Pod traffic is restricted by having a Network Policy that | ||||||
selects it (through the use of labels). Once there is any Network Policy in a | ||||||
namespace selecting a particular pod, that pod will reject any connections | ||||||
that are not allowed by any Network Policy. Other pods in the namespace that | ||||||
are not selected by any Network Policy will continue to accept all traffic. | ||||||
Implementing Kubernetes Network Policies with minimal allowed communication enhances security | ||||||
by reducing entry points and limiting attacker movement within the cluster. It ensures pods and | ||||||
services communicate only with necessary entities, reducing unauthorized access risks. In case | ||||||
of a breach, these policies contain compromised pods, preventing widespread malicious activity. | ||||||
Additionally, they enhance monitoring and detection of anomalous network activities. | ||||||
severity: medium | ||||||
|
||||||
identifiers: {} | ||||||
|
||||||
references: | ||||||
bsi: APP.4.4.A19 | ||||||
|
||||||
ocil_clause: 'Network Policies need to be evaluated if they are appropriate' | ||||||
|
||||||
ocil: |- | ||||||
For each non-default namespace in the cluster, review the configured Network Policies | ||||||
and ensure that they only allow the necessary network network connections. They should should | ||||||
precisely define source and target using label selectors and ports. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you please resolve the typo issue. Should be, |
||||||
1. Get a list of existing projects(namespaces), exclude default, kube-*, openshift-* | ||||||
<pre>$ oc get namespaces -ojson | jq -r '[.items[] | select((.metadata.name | startswith("openshift") | not) and (.metadata.name | startswith("kube-") | not) and .metadata.name != "default") | .metadata.name]'</pre> | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. imho we should make the list of exceptions configurable. There are customers, which have applications running which they want to exclude from such a rule or they want to not exclude the default namespaces. Furthermore some of them might install operators to non-default namespaces. |
||||||
2. For each of these namespaces, review the network policies: | ||||||
<pre>$ oc get networkpolicies -n $namespace -o yaml</pre> |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -34,6 +34,7 @@ ocil: |- | |
return true. | ||
|
||
references: | ||
bsi: APP.4.4.A18 | ||
srg: SRG-APP-000039-CTR-000110 | ||
|
||
identifiers: | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -425,18 +425,45 @@ controls: | |
levels: | ||
- elevated | ||
description: >- | ||
Pods SHOULD ONLY be able to communicate with each other through the necessary network | ||
ports, even within a Kubernetes namespace. There SHOULD be rules within the CNI that | ||
disallow all but the necessary network connections within the Kubernetes namespace. These | ||
(1) Pods SHOULD ONLY be able to communicate with each other through the necessary network | ||
ports, even within a Kubernetes namespace. (2) There SHOULD be rules within the CNI that | ||
disallow all but the necessary network connections within the Kubernetes namespace. (3) These | ||
rules SHOULD precisely define the source and destination of the allowed connections using at | ||
least one of the following criteria: service name, metadata (“labels”), Kubernetes service | ||
accounts, or certificate-based authentication. | ||
All the criteria used as labels for a connection SHOULD be secured in such a way that they can | ||
only be changed by authorised persons and management services. | ||
(4) All the criteria used as labels for a connection SHOULD be secured in such a way that they | ||
can only be changed by authorised persons and management services. | ||
notes: >- | ||
TBD | ||
status: pending | ||
rules: [] | ||
In a cluster using a network plugin that supports Kubernetes network policy, network isolation | ||
is controlled entirely by NetworkPolicy objects. In OpenShift, the default plugins (OpenShift SDN, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we should remove OpenShift SDN as it is deprecated |
||
OVN Kubernetes) supports using network policy. Support for NetworkPolicy objects is verified | ||
using rules. | ||
|
||
Section 1-3: By default, all pods in a project are accessible from other pods and network endpoints. | ||
To isolate one or more pods in a project, you need to create NetworkPolicy objects in that project | ||
to indicate the allowed incoming connections. If a pod is matched by selectors in one or more | ||
NetworkPolicy objects, then the pod will accept only connections that are allowed by at least | ||
one of those NetworkPolicy objects. A pod that is not selected by any NetworkPolicy objects | ||
is fully accessible. | ||
|
||
It is useful to create default policies for each application namespace e.g. to deny all ingress | ||
traffic by default. The existance of at least one network policy and the automatic creation | ||
as part of a namespace template is checked using rules. | ||
|
||
The creation of suitable NetworkPolicy objects that satisfy the requirements from sections 1 to 3, | ||
however, needs to be ensured by the application owner. A manual rule is provided for that. | ||
|
||
Section 4: It needs to be ensured organizationally, that only required subjects are granted | ||
RBAC to change the relevant Kubernetes objects. | ||
status: partial | ||
rules: | ||
# General support of network policies | ||
- configure_network_policies | ||
# Section 1-2 | ||
- configure_network_policies_namespaces | ||
- project_config_and_template_network_policy | ||
# Section 3 | ||
- configure_appropriate_network_policies | ||
|
||
- id: APP.4.4.A19 | ||
title: High Availability of Kubernetes | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.