Skip to content

Commit 7a0b7d3

Browse files
aireillyaireilly
authored
Merge pull request #10 from aireilly/main
Refactoring security section to facilitate reuse
2 parents 5b7e108 + da289f0 commit 7a0b7d3

7 files changed

+110
-106
lines changed

‎main.adoc‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -67,6 +67,16 @@ include::modules/cnf-best-practices-user-plane-cnfs.adoc[leveloffset=+2]
6767

6868
include::modules/cnf-best-practices-developer-guide.adoc[leveloffset=+1]
6969

70+
include::modules/cnf-best-practices-refactoring.adoc[leveloffset=+2]
71+
72+
include::modules/cnf-best-practices-cnf-security.adoc[leveloffset=+2]
73+
74+
include::modules/cnf-best-practices-avoid-accessing-resource-on-host.adoc[leveloffset=+3]
75+
76+
include::modules/cnf-best-practices-avoid-mounting-host-directories-as-volumes.adoc[leveloffset=+3]
77+
78+
include::modules/cnf-best-practices-avoid-the-host-network-namespace.adoc[leveloffset=+3]
79+
7080
include::modules/cnf-best-practices-linux-capabilities.adoc[leveloffset=+2]
7181

7282
include::modules/cnf-best-practices-openshift-operations.adoc[leveloffset=+2]

‎modules/cnf-best-practices-avoid-accessing-resource-on-host.adoc‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
[id="cnf-best-practices-avoid-accessing-resource-on-host"]
2+
= Avoid accessing resource on host
3+
4+
It is not recommended for an application to access following resources on the host.

‎modules/cnf-best-practices-avoid-mounting-host-directories-as-volumes.adoc‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
[id="cnf-best-practices-avoid-mounting-host-directories-as-volumes"]
2+
= Avoid mounting host directories as volumes
3+
4+
It is not necessary to mount host `/sys/` or host `/dev/` directories as a volume in a pod in order to use a network device such as SR-IOV VF. The moving of a network interface into the pod network namespace is done automatically by CNI. Mounting the whole `/sys/` or `/dev/` directory in the container will overwrite the network device descriptor inside the container which causes `device not found` or `no such file or directory` error.
5+
6+
Network interface statistics can be queried inside the container using the same `/sys/` path as was done when running directly on the host. When running network interfaces in containers, relevant `/sys/` statistics interfaces are available inside the container, such as `/sys/class/net/net1/statistics/`, `/proc/net/tcp` and `/proc/net/tcp6`.
7+
8+
For running DPDK applications with SR-IOV VF, device specs (in case of vfio-pci) are automatically attached to the container via the Device Plugin. There is no need to mount the /dev/ directory as a volume in the container as the application can find device specs under `/dev/vfio/` in the container.

‎modules/cnf-best-practices-avoid-the-host-network-namespace.adoc‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
[id="cnf-best-practices-avoid-the-host-network-namespace"]
2+
= Avoid the host network namespace
3+
4+
Application pods must avoid using `hostNetwork`. Applications may not use the host network, including `nodePort` for network communication. Any networking needs beyond the functions provided by the pod network and ingress/egress proxy must be serviced via a MULTUS connected interface.
5+
6+
.CNF requirement
7+
[IMPORTANT]
8+
====
9+
Applications may not use `NodePorts` or the `hostNetwork`.
10+
11+
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-service-type[access-control-service-type]
12+
====

‎modules/cnf-best-practices-cnf-security.adoc‎

Lines changed: 64 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
[id="cnf-best-practices-cnf-security"]
2+
= CNF security
3+
4+
In OCP, it is possible to run privileged containers that have all of the root capabilities on a host machine, allowing the ability to access resources which are not accessible in ordinary containers. This, however, increases the security risk to the whole cluster. Containers should only request those privileges they need to run their legitimate functions. No containers will be allowed to run with full privileges without an exception.
5+
6+
The general guidelines are:
7+
8+
. Only ask for the necessary privileges and access control settings for your application.
9+
10+
. If the function required by your CNF can be fulfilled by OCP components, your application should not be requesting escalated privilege to perform this function.
11+
12+
. Avoid using any host system resource if possible.
13+
14+
. Leveraging read only root filesystem when possible.
15+
16+
.CNF requirement
17+
[IMPORTANT]
18+
====
19+
Only ask for the necessary privileges and access control settings for your application
20+
21+
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-security-context-non-root-user-check[access-control-security-context-non-root-user-check]
22+
====
23+
24+
.CNF requirement
25+
[IMPORTANT]
26+
====
27+
If the function required by your CNF can be fulfilled by OCP components, your application should not be
28+
requesting escalated privilege to perform this function.
29+
30+
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-security-context-privilege-escalation[access-control-security-context-privilege-escalation]
31+
====
32+
33+
.CNF requirement
34+
[IMPORTANT]
35+
====
36+
Avoid using any host system resource.
37+
38+
See test cases link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-host-ipc[access-control-pod-host-ipc],
39+
link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-host-pid[access-control-pod-host-pid]
40+
====
41+
42+
.CNF requirement
43+
[IMPORTANT]
44+
====
45+
Do not mount host directories for device access.
46+
47+
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-host-path[access-control-pod-host-path]
48+
====
49+
50+
.CNF requirement
51+
[IMPORTANT]
52+
====
53+
Do not use host network namespace.
54+
55+
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-namespace[access-control-namespace]
56+
====
57+
58+
.CNF requirement
59+
[IMPORTANT]
60+
====
61+
CNFs may not modify the platform in any way.
62+
63+
See test cases link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#platform-alteration-base-image[platform-alteration-base-image], link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#platform-alteration-sysctl-config[platform-alteration-sysctl-config]
64+
====

‎modules/cnf-best-practices-developer-guide.adoc‎

Lines changed: 1 addition & 106 deletions
Original file line numberDiff line numberDiff line change
@@ -16,109 +16,4 @@ This document is mainly for the developers of CNFs, who need to build high-perfo
1616
[id="cnf-best-practices-non-goal"]
1717
== Non-goal
1818

19-
This is not a guide on how to build CNF’s functionality.
20-
21-
[id="cnf-best-practices-refactoring"]
22-
== Refactoring
23-
24-
NFs should break their software down into the smallest set of microservices as possible. Running monolithic applications inside of a container is not the operating model to be in.
25-
26-
It is hard to move a 1000LB boulder. However, it is easy when that boulder is broken down into many pieces (pebbles). All containerized network functions (CNFs) should break apart each piece of the functions/services/processes into separate containers. These containers will still be within kubernetes pods and all of the functions that perform a single task should be within the same namespace.
27-
28-
There is a link:https://martinfowler.com/microservices/[quote] from Lewis and Fowler that describes this best:
29-
30-
[quote, Lewis and Fowler]
31-
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.These services are built around business capabilities and independently deployable by fully automated deployment machinery.
32-
33-
[id="cnf-best-practices-cnf-security"]
34-
== CNF security
35-
36-
In OCP, it is possible to run privileged containers that have all of the root capabilities on a host machine, allowing the ability to access resources which are not accessible in ordinary containers. This, however, increases the security risk to the whole cluster. Containers should only request those privileges they need to run their legitimate functions. No containers will be allowed to run with full privileges without an exception.
37-
38-
The general guidelines are:
39-
40-
. Only ask for the necessary privileges and access control settings for your application.
41-
42-
. If the function required by your CNF can be fulfilled by OCP components, your application should not be requesting escalated privilege to perform this function.
43-
44-
. Avoid using any host system resource if possible.
45-
46-
. Leveraging read only root filesystem when possible.
47-
48-
.CNF requirement
49-
[IMPORTANT]
50-
====
51-
Only ask for the necessary privileges and access control settings for your application
52-
53-
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-security-context-non-root-user-check[access-control-security-context-non-root-user-check]
54-
====
55-
56-
.CNF requirement
57-
[IMPORTANT]
58-
====
59-
If the function required by your CNF can be fulfilled by OCP components, your application should not be
60-
requesting escalated privilege to perform this function.
61-
62-
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-security-context-privilege-escalation[access-control-security-context-privilege-escalation]
63-
====
64-
65-
.CNF requirement
66-
[IMPORTANT]
67-
====
68-
Avoid using any host system resource.
69-
70-
See test cases link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-host-ipc[access-control-pod-host-ipc],
71-
link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-host-pid[access-control-pod-host-pid]
72-
====
73-
74-
.CNF requirement
75-
[IMPORTANT]
76-
====
77-
Do not mount host directories for device access.
78-
79-
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-host-path[access-control-pod-host-path]
80-
====
81-
82-
.CNF requirement
83-
[IMPORTANT]
84-
====
85-
Do not use host network namespace.
86-
87-
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-namespace[access-control-namespace]
88-
====
89-
90-
.CNF requirement
91-
[IMPORTANT]
92-
====
93-
CNFs may not modify the platform in any way.
94-
95-
See test cases link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#platform-alteration-base-image[platform-alteration-base-image], link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#platform-alteration-sysctl-config[platform-alteration-sysctl-config]
96-
====
97-
98-
[id="cnf-best-practices-avoid-accessing-resource-on-host"]
99-
=== Avoid accessing resource on host
100-
101-
It is not recommended for an application to access following resources on the host.
102-
103-
[id="cnf-best-practices-avoid-mounting-host-directories-as-volumes"]
104-
=== Avoid mounting host directories as volumes
105-
106-
It is not necessary to mount host `/sys/` or host `/dev/` directories as a volume in a pod in order to use a network device such as SR-IOV VF. The moving of a network interface into the pod network namespace is done automatically by CNI. Mounting the whole `/sys/` or `/dev/` directory in the container will overwrite the network device descriptor inside the container which causes `device not found` or `no such file or directory` error.
107-
108-
Network interface statistics can be queried inside the container using the same `/sys/` path as was done when running directly on the host. When running network interfaces in containers, relevant `/sys/` statistics interfaces are available inside the container, such as `/sys/class/net/net1/statistics/`, `/proc/net/tcp` and `/proc/net/tcp6`.
109-
110-
For running DPDK applications with SR-IOV VF, device specs (in case of vfio-pci) are automatically attached to the container via the Device Plugin. There is no need to mount the /dev/ directory as a volume in the container as the application can find device specs under `/dev/vfio/` in the container.
111-
112-
[id="cnf-best-practices-avoid-the-host-network-namespace"]
113-
=== Avoid the host network namespace
114-
115-
Application pods must avoid using `hostNetwork`. Applications may not use the host network, including `nodePort` for network communication. Any networking needs beyond the functions provided by the pod network and ingress/egress proxy must be serviced via a MULTUS connected interface.
116-
117-
.CNF requirement
118-
[IMPORTANT]
119-
====
120-
Applications may not use `NodePorts` or the `hostNetwork`.
121-
122-
See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-service-type[access-control-service-type]
123-
====
124-
19+
This is not a guide on how to build CNF functionality.

‎modules/cnf-best-practices-refactoring.adoc‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
[id="cnf-best-practices-refactoring"]
2+
= Refactoring
3+
4+
NFs should break their software down into the smallest set of microservices as possible. Running monolithic applications inside of a container is not the operating model to be in.
5+
6+
It is hard to move a 1000LB boulder. However, it is easy when that boulder is broken down into many pieces (pebbles). All containerized network functions (CNFs) should break apart each piece of the functions/services/processes into separate containers. These containers will still be within kubernetes pods and all of the functions that perform a single task should be within the same namespace.
7+
8+
There is a link:https://martinfowler.com/microservices/[quote] from Lewis and Fowler that describes this best:
9+
10+
[quote, Lewis and Fowler]
11+
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.These services are built around business capabilities and independently deployable by fully automated deployment machinery.

0 commit comments

Comments
 (0)