Add impact statements

Comments from Banashri
Add Makefile to build index.html and main.pdf guides

Author: edcdavid

Makefile

@@ -0,0 +1,95 @@
+# Makefile for building Red Hat Best Practices Guide
+# Builds both HTML and PDF outputs using containerized build process
+
+# Variables
+PODMAN := podman
+MAIN_DOC := main.adoc
+HTML_TEMPLATE := quay.io/redhat-docs/redhat-docs-template
+PDF_TEMPLATE := quay.io/redhat-docs/redhat-docs-pdf-template
+ASSETS_DIR := assets
+PDF_ASSETS_DIR := pdf-assets
+OUTPUT_HTML := index.html
+OUTPUT_PDF := main.pdf
+
+# Default target
+.PHONY: all
+all: html pdf
+
+# Help target
+.PHONY: help
+help:
+	@echo "Red Hat Best Practices Guide Build System"
+	@echo "=========================================="
+	@echo ""
+	@echo "Available targets:"
+	@echo "  all       - Build both HTML and PDF (default)"
+	@echo "  html      - Build HTML output (index.html)"
+	@echo "  pdf       - Build PDF output (main.pdf)"
+	@echo "  clean     - Remove generated files and assets"
+	@echo "  help      - Show this help message"
+	@echo ""
+	@echo "Requirements:"
+	@echo "  - podman must be installed and available in PATH"
+	@echo "  - Internet connection for pulling container images"
+
+# Build HTML output
+.PHONY: html
+html: $(OUTPUT_HTML)
+
+$(OUTPUT_HTML): $(MAIN_DOC) $(ASSETS_DIR)
+	@echo "Building HTML output..."
+	$(PODMAN) run --rm -it -v "$(CURDIR)":/docs:Z $(HTML_TEMPLATE) $(MAIN_DOC)
+	@echo "HTML build complete: $(OUTPUT_HTML)"
+
+# Set up HTML assets
+$(ASSETS_DIR):
+	@echo "Setting up HTML assets..."
+	$(PODMAN) pull $(HTML_TEMPLATE)
+	$(PODMAN) cp $$($(PODMAN) run --detach $(HTML_TEMPLATE)):/assets ./$(ASSETS_DIR)
+
+# Build PDF output
+.PHONY: pdf
+pdf: $(OUTPUT_PDF)
+
+$(OUTPUT_PDF): $(MAIN_DOC) $(PDF_ASSETS_DIR)
+	@echo "Building PDF output..."
+	$(PODMAN) run --rm -it -v "$(CURDIR)":/docs:Z $(PDF_TEMPLATE) $(MAIN_DOC)
+	@echo "PDF build complete: $(OUTPUT_PDF)"
+
+# Set up PDF assets
+$(PDF_ASSETS_DIR):
+	@echo "Setting up PDF assets..."
+	$(PODMAN) pull $(PDF_TEMPLATE)
+	$(PODMAN) cp $$($(PODMAN) run --detach $(PDF_TEMPLATE)):/pdf-assets ./$(PDF_ASSETS_DIR)
+
+# Clean generated files
+.PHONY: clean
+clean:
+	@echo "Cleaning generated files..."
+	rm -f $(OUTPUT_HTML) $(OUTPUT_PDF)
+	rm -rf $(ASSETS_DIR) $(PDF_ASSETS_DIR)
+	@echo "Clean complete"
+
+# Force rebuild targets
+.PHONY: force-html force-pdf
+force-html: clean-html html
+force-pdf: clean-pdf pdf
+
+# Clean specific outputs
+.PHONY: clean-html clean-pdf
+clean-html:
+	rm -f $(OUTPUT_HTML)
+	rm -rf $(ASSETS_DIR)
+
+clean-pdf:
+	rm -f $(OUTPUT_PDF)
+	rm -rf $(PDF_ASSETS_DIR)
+
+# Check if podman is available
+.PHONY: check-podman
+check-podman:
+	@which $(PODMAN) > /dev/null || (echo "Error: $(PODMAN) not found. Please install podman." && exit 1)
+
+# Make all build targets depend on podman check
+html: check-podman
+pdf: check-podman 

modules/k8s-best-practices-affinity-anti-affinity.adoc

@@ -34,6 +34,8 @@ Pods that need to be co-located on the same node need affinity rules. Pods that
 co-located for resiliency purposes require anti-affinity rules.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-affinity-required-pods[lifecycle-affinity-required-pods]
+
+**Impacts and Risks of Non-Compliance:** Missing affinity rules can cause incorrect pod placement, leading to performance issues and failure to meet co-location requirements.
 ====
 
 .Workload requirement
@@ -43,5 +45,7 @@ Pods that perform the same microservice and could be disrupted if multiple membe
 unavailable must implement affinity/anti-affinity group rules or spread the pods across nodes to prevent disruption in the event of node failures, patches, or upgrades.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-pod-high-availability[lifecycle-pod-high-availability]
+
+**Impacts and Risks of Non-Compliance:** Missing anti-affinity rules can cause all pod replicas to be scheduled on the same node, creating single points of failure.
 ====
 

modules/k8s-best-practices-automount-services-for-pods.adoc

@@ -18,3 +18,5 @@ Pods must include an explicit `serviceAccountName` in the pod spec. This is requ
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-automount-service-account-token[access-control-pod-automount-service-account-token]
 
+**Impacts and Risks of Non-Compliance:** Auto-mounted service account tokens expose Kubernetes API credentials to application code, creating potential attack vectors if applications are compromised.
+

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

@@ -9,4 +9,6 @@ Application pods must avoid using `hostNetwork`. Applications may not use the ho
 Applications may not use `NodePorts` or the `hostNetwork`.
 
 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]
+
+**Impacts and Risks of Non-Compliance:** NodePort services expose applications directly on host ports, creating security risks and potential port conflicts with host services.
 ====

modules/k8s-best-practices-cloud-native-design-best-practices.adoc

@@ -12,7 +12,13 @@ A container must provide APIs for the platform to observe the container health a
 Lifecycle conformance::
 A container must receive important events from the platform and conform/react to these events properly. For example, a container should catch SIGTERM or SIGKILL from the platform and shut down as quickly as possible. Other typically important events from the platform are PostStart to initialize before servicing requests and PreStop to release resources cleanly before shutting down.
 
-See test cases link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-container-shutdown[lifecycle-container-shutdown], link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-container-startup[lifecycle-container-startup]
+See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-container-poststart[lifecycle-container-poststart]
+
+**Impacts and Risks of Non-Compliance:** Missing PostStart hooks can cause containers to start serving traffic before proper initialization, leading to application errors.
+
+See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-container-prestop[lifecycle-container-prestop]
+
+**Impacts and Risks of Non-Compliance:** Missing PreStop hooks can cause ungraceful shutdowns, data loss, and connection drops during container termination.
 
 Image immutability::
 Container images are meant to be immutable; i.e. customized images for different environments should typically not be built. Instead, an external means for storing and retrieving configurations that vary across environments for the container should be used. Additionally, the container image should NOT dynamically install additional packages at runtime.

modules/k8s-best-practices-cnf-operator-requirements.adoc

@@ -7,6 +7,8 @@
 Operators should be certified against the openshift version of the cluster they will be deployed on.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#affiliated-certification-operator-is-certified[affiliated-certification-operator-is-certified]
+
+**Impacts and Risks of Non-Compliance:** Uncertified operators may have security flaws, compatibility issues, and lack enterprise support, creating operational risks.
 ====
 
 .Workload requirement
@@ -19,6 +21,8 @@ Operators must be compatible with our version of openshift
 * See link:https://sdk.operatorframework.io/docs/best-practices/[Redhat Operator SDK & Best Practices], link:https://olm.operatorframework.io/docs/best-practices/[OLM Best Practices]
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#platform-alteration-ocp-lifecycle[platform-alteration-ocp-lifecycle]
+
+**Impacts and Risks of Non-Compliance:** End-of-life OpenShift versions lack security updates and support, creating significant security and operational risks.
 ====
 
 .Workload requirement
@@ -27,6 +31,8 @@ See test case link:https://github.com/test-network-function/cnf-certification-te
 Operators must be in OLM bundle format (Operator Framework).
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#operator-install-source[operator-install-source]
+
+**Impacts and Risks of Non-Compliance:** Non-OLM operators bypass lifecycle management and dependency resolution, creating operational complexity and update issues.
 ====
 
 .Workload requirement
@@ -47,6 +53,8 @@ All custom resources for operators require podspecs for both pod image override
 Operators must not use daemonsets
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-pod-owner-type[lifecycle-pod-owner-type]
+
+**Impacts and Risks of Non-Compliance:** Naked pods and DaemonSets lack proper lifecycle management, making updates, scaling, and recovery operations difficult or impossible.
 ====
 
 .Workload requirement
@@ -87,6 +95,8 @@ For requesting Global operators (upstream 3rd party shared operators), the opera
 Operators that are proprietary to a workload application must ensure that their CRD's are unique, and will not conflict with other operators in the cluster.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#observability-crd-status[observability-crd-status]
+
+**Impacts and Risks of Non-Compliance:** Missing status subresources prevent proper monitoring and automation based on custom resource states.
 ====
 
 .Workload requirement
@@ -101,6 +111,8 @@ If a workload application requires a specific version of a third party non-propr
 Successful operator installation and runtime must be validated in pre-deployment lab environments before being allowed to be deployed to production.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#operator-install-status-succeeded[operator-install-status-succeeded]
+
+**Impacts and Risks of Non-Compliance:** Failed operator installations can leave applications in incomplete states, causing functionality gaps and operational issues.
 ====
 
 .Workload requirement

modules/k8s-best-practices-cnf-securing-cnf-networks.adoc

@@ -9,4 +9,6 @@ Workloads must have the least permissions possible and must implement Network Po
 Applications must define network policies that permit only the minimum network access the application needs to function.
 
 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]
+
+**Impacts and Risks of Non-Compliance:** Without default deny-all network policies, workloads are exposed to lateral movement attacks and unauthorized network access, compromising security posture and potentially enabling data breaches.
 ====

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

@@ -18,7 +18,9 @@ The general guidelines are:
 ====
 Only ask for the necessary privileges and access control settings for your application
 
-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]
+See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-security-context-non-root-user-id-check[access-control-security-context-non-root-user-id-check]
+
+**Impacts and Risks of Non-Compliance:** Running containers as root increases the blast radius of security vulnerabilities and can lead to full host compromise if containers are breached.
 ====
 
 .Workload requirement
@@ -28,6 +30,8 @@ If the function required by your workload can be fulfilled by OCP components, yo
 requesting escalated privilege to perform this function.
 
 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]
+
+**Impacts and Risks of Non-Compliance:** Allowing privilege escalation can lead to containers gaining root access, compromising the security boundary between containers and hosts.
 ====
 
 .Workload requirement
@@ -37,6 +41,8 @@ Avoid using any host system resource.
 
 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], 
 link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-pod-host-pid[access-control-pod-host-pid]
+
+**Impacts and Risks of Non-Compliance:** Host IPC access allows containers to communicate with host processes, potentially exposing sensitive information and enabling privilege escalation.
 ====
 
 .Workload requirement
@@ -45,6 +51,8 @@ link:https://github.com/test-network-function/cnf-certification-test/blob/main/C
 Do not mount host directories for device access.
 
 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]
+
+**Impacts and Risks of Non-Compliance:** Host path mounts can expose sensitive host files to containers, enable container escape attacks, and compromise host system integrity.
 ====
 
 .Workload requirement
@@ -53,6 +61,8 @@ See test case link:https://github.com/test-network-function/cnf-certification-te
 Do not use host network namespace.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#access-control-namespace[access-control-namespace]
+
+**Impacts and Risks of Non-Compliance:** Using inappropriate namespaces can lead to resource conflicts, security boundary violations, and administrative complexity in multi-tenant environments.
 ====
 
 .Workload requirement
@@ -61,4 +71,6 @@ See test case link:https://github.com/test-network-function/cnf-certification-te
 Workloads may not modify the platform in any way.
 
 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]
+
+**Impacts and Risks of Non-Compliance:** Modified base images can introduce security vulnerabilities, create inconsistent behavior, and violate immutable infrastructure principles.
 ====

modules/k8s-best-practices-container-runtime.adoc

@@ -11,6 +11,8 @@ Images should be OCI compliant. Red Hat recommends that you build images using R
 See <<k8s-best-practices-ubi>> for additional information about UBI and support.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#platform-alteration-isredhat-release[platform-alteration-isredhat-release]
+
+**Impacts and Risks of Non-Compliance:** Non-Red Hat base images may lack security updates, enterprise support, and compliance certifications required for production use.
 ====
 
 For more information about CRI-O, see the following:

modules/k8s-best-practices-cpu-isolation.adoc

@@ -11,5 +11,7 @@ Device interrupts are load balanced between all isolated and reserved CPUs to av
 To use isolated CPUs, specific annotations must be defined in the pod specification.
 
 See test case link:https://github.com/test-network-function/cnf-certification-test/blob/main/CATALOG.md#lifecycle-cpu-isolation[lifecycle-cpu-isolation]
+
+**Impacts and Risks of Non-Compliance:** Improper CPU isolation can cause performance interference between workloads and fail to provide guaranteed compute resources.
 ====