Merge pull request #11 from aireilly/main

fixes section offset and other errors

Author: aireilly

main.adoc

@@ -5,7 +5,6 @@ Cloud-native network functions (CNFs) best practices
 :revdate: 2023
 :toc: left
 :toclevels: 5
-:toc-title: CNF Best Practices v{revnumber}
 :repo-url: https://github.com/test-network-function/cnf-best-practices
 :icons: image
 :icontype: svg
@@ -81,6 +80,10 @@ include::modules/cnf-best-practices-linux-capabilities.adoc[leveloffset=+2]
 
 include::modules/cnf-best-practices-openshift-operations.adoc[leveloffset=+2]
 
+include::modules/cnf-best-practices-secrets-management.adoc[leveloffset=+3]
+
+include::modules/cnf-best-practices-scc-permissions-for-an-application.adoc[leveloffset=+3]
+
 include::modules/cnf-best-practices-expectations-permissions.adoc[leveloffset=+2]
 
 include::modules/cnf-best-practices-cloud-native-design-best-practices.adoc[leveloffset=+3]

modules/cnf-best-practices-disruption-budgets.adoc

@@ -1,5 +1,5 @@
 [id="cnf-best-practices-disruption-budgets"]
-==== Disruption budgets
+= Disruption budgets
 
 When managing the platform there are at least two types of disruptions that can occur. They are voluntary and involuntary. When dealing with voluntary disruptions a pod disruption budget can be set that determines how many replicas of the application must remain running at any given time. For example, consider the case where an administrator is shutting down a node for
 

modules/cnf-best-practices-openshift-operations.adoc

@@ -217,17 +217,3 @@ Applications must define network policies that permit only the minimum network a
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#networking-network-policy-deny-all[networking-network-policy-deny-all]
 ====
-
-[id="cnf-best-practices-secrets-management"]
-== Managing secrets
-
-Secrets objects in OpenShift provide a way to hold sensitive information such as passwords, config files and credentials. There are 4 types of secrets; service account, basic auth, ssh auth and TLS. Secrets can be added via deployment configurations or consumed by pods directly. For more information on secrets and examples, see the following documentation.
-
-link:https://docs.openshift.com/container-platform/latest/nodes/pods/nodes-pods-secrets.html[Providing sensitive data to pods]
-
-[id="cnf-best-practices-scc-permissions-for-an-application"]
-== Setting SCC permissions for applications
-
-Permissions to use an SCC is done by adding a cluster role that has _uses_ permissions for the SCC and then rolebindings for the users within a namespace to that role for users that need that SCC. Application admins can create their own role/rolebindings to assign permissions to a Service Account.
-
-

modules/cnf-best-practices-scc-permissions-for-an-application.adoc

@@ -0,0 +1,4 @@
+[id="cnf-best-practices-scc-permissions-for-an-application"]
+= Setting SCC permissions for applications
+
+Permissions to use an SCC is done by adding a cluster role that has _uses_ permissions for the SCC and then rolebindings for the users within a namespace to that role for users that need that SCC. Application admins can create their own role/rolebindings to assign permissions to a Service Account.

modules/cnf-best-practices-secrets-management.adoc

@@ -0,0 +1,6 @@
+[id="cnf-best-practices-secrets-management"]
+= Managing secrets
+
+Secrets objects in OpenShift provide a way to hold sensitive information such as passwords, config files and credentials. There are 4 types of secrets; service account, basic auth, ssh auth and TLS. Secrets can be added via deployment configurations or consumed by pods directly. For more information on secrets and examples, see the following documentation.
+
+link:https://docs.openshift.com/container-platform/latest/nodes/pods/nodes-pods-secrets.html[Providing sensitive data to pods]