TELCODOCS#2004: Day 2 Operations - Security Doc

_topic_maps/_topic_map.yml

@@ -3474,6 +3474,15 @@ Topics:
     Topics:
     - Name: Observability in OpenShift Container Platform
       File: telco-observability
+  - Name: Security
+    Dir: security
+    Topics:
+    - Name: Security basics
+      File: telco-security-basics
+    - Name: Host security
+      File: telco-security-host-sec
+    - Name: Security context constraints
+      File: telco-security-sec-context-constraints
 ---
 Name: Specialized hardware and driver enablement
 Dir: hardware_enablement

edge_computing/day_2_core_cnf_clusters/security/_attributes

@@ -0,0 +1 @@
+../../../_attributes/

edge_computing/day_2_core_cnf_clusters/security/images

@@ -0,0 +1 @@
+../../../images/

edge_computing/day_2_core_cnf_clusters/security/modules

@@ -0,0 +1 @@
+../../../modules/

edge_computing/day_2_core_cnf_clusters/security/snippets

@@ -0,0 +1 @@
+../../../snippets/

edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc

@@ -0,0 +1,56 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="telco-security-basics"]
+= Security basics
+include::_attributes/common-attributes.adoc[]
+:context: telco-security-basics
+
+toc::[]
+
+Security is a critical component of telecommunications deployments on {product-title}, particularly when running cloud-native network functions (CNFs). 
+
+You can enhance security for high-bandwidth network deployments in telecommunications (telco) environments by following key security considerations. By implementing these standards and best practices, you can strengthen security in telco-specific use cases.
+
+include::modules/telco-security-rbac-overview.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/using-rbac.adoc#authorization-overview_using-rbac[Using RBAC to define and apply permissions]
+
+include::modules/telco-security-sec-accounts-overview.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/understanding-and-creating-service-accounts.adoc[Understanding and creating service accounts]
+
+include::modules/telco-security-identity-prov-config.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/understanding-identity-provider.adoc[Understanding identity provider configuration]
+
+include::modules/telco-security-replacing-kubeadmin-user.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/identity_providers/configuring-htpasswd-identity-provider.adoc#identity-provider-htpasswd-about_configuring-htpasswd-identity-provider[About htpasswd authentication]
+
+include::modules/telco-security-sec-considerations-telco.adoc[leveloffset=+1]
+
+include::modules/telco-security-pod-sec-in-kub-and-ocp.adoc[leveloffset=+1]
+
+include::modules/telco-security-key-areas-for-cnf-deploy.adoc[leveloffset=+1]
+
+include::modules/telco-security-infra.adoc[leveloffset=+1]
+
+include::modules/telco-security-lifecycle-mgmnt.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+xref:../../../edge_computing/day_2_core_cnf_clusters/updating/telco-update-welcome.adoc[Upgrading a telco core CNF clusters]
+
+include::modules/telco-security-evolu-nf-to-cnf.adoc[leveloffset=+1]

edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc

@@ -0,0 +1,27 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="telco-security-host-sec"]
+= Host security
+include::_attributes/common-attributes.adoc[]
+:context: telco-security-host-sec
+
+toc::[]
+
+include::modules/telco-security-rhcos-overview.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../architecture/architecture-rhcos.adoc#rhcos-about_architecture-rhcos[About RHCOS]
+
+* xref:../../../architecture/architecture-rhcos.adoc[Red Hat Enterprise Linux CoreOS (RHCOS)].
+
+* xref:../../../edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc#telco-security-linux-capabilities-overview_telco-security-host-sec[Linux capabilities].
+
+include::modules/telco-security-command-line-host-access.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../support/troubleshooting/investigating-pod-issues.adoc#starting-debug-pods-with-root-access_investigating-pod-issues[Starting debug pods with root access].
+
+include::modules/telco-security-linux-capabilities-overview.adoc[leveloffset=+1]

edge_computing/day_2_core_cnf_clusters/security/telco-security-sec-context-constraints.adoc

@@ -0,0 +1,96 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="telco-security-sec-context-constraints"]
+= Security context constraints
+include::_attributes/common-attributes.adoc[]
+:context: telco-security-sec-context-constraints
+:imagesdir: images
+
+toc::[]
+
+Similar to the way that RBAC resources control user access, administrators can use security context constraints (SCCs) to control permissions for pods. These permissions determine the actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run.
+
+Security context constraints allow an administrator to control the following security constraints:
+
+* Whether a pod can run privileged containers with the `allowPrivilegedContainer` flag
+* Whether a pod is constrained with the `allowPrivilegeEscalation` flag
+* The capabilities that a container can request
+* The use of host directories as volumes
+* The SELinux context of the container
+* The container user ID
+* The use of host namespaces and networking
+* The allocation of an `FSGroup` that owns the pod volumes
+* The configuration of allowable supplemental groups
+* Whether a container requires write access to its root file system
+* The usage of volume types
+* The configuration of allowable `seccomp` profiles
+
+Default SCCs are created during installation and when you install some Operators or other components. As a cluster administrator, you can also create your own SCCs by using the OpenShift CLI (`oc`).
+
+For information about default security context constraints, see xref:../../../authentication/managing-security-context-constraints.adoc#default-sccs_configuring-internal-oauth[Default security context constraints].
+
+[IMPORTANT]
+====
+Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or {product-title} is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.
+
+Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see xref:../../../authentication/managing-security-context-constraints.adoc#security-context-constraints-creating_configuring-internal-oauth[Creating security context constraints].
+====
+
+You can use the following basic SCCs:
+
+* `restricted`
+* `restricted-v2`
+
+The `restricted-v2` SCC is the most restrictive SCC provided by a new installation and is used by default for authenticated users. It aligns with Pod Security Admission (PSA) restrictions and improves security, as the original `restricted` SCC is less restrictive. It also helps transition from the original SCCs to v2 across multiple releases. Eventually, the original SCCs get deprecated. Therefore, it is recommended to use the `restricted-v2` SCC.
+
+You can examine the `restricted-v2` SCC by running the following command:
+[source,terminal]
+----
+$ oc describe scc restricted-v2
+----
+.Example output
+[source,terminal]
+----
+Name:                                           restricted-v2
+Priority:                                       <none>
+Access:
+  Users:                                        <none>
+  Groups:                                       <none>
+Settings:
+  Allow Privileged:                             false
+  Allow Privilege Escalation:                   false
+  Default Add Capabilities:                     <none>
+  Required Drop Capabilities:                   ALL
+  Allowed Capabilities:                         NET_BIND_SERVICE
+  Allowed Seccomp Profiles:                     runtime/default
+  Allowed Volume Types:                         configMap,downwardAPI,emptyDir,ephemeral,persistentVolumeClaim,projected,secret
+  Allowed Flexvolumes:                          <all>
+  Allowed Unsafe Sysctls:                       <none>
+  Forbidden Sysctls:                            <none>
+  Allow Host Network:                           false
+  Allow Host Ports:                             false
+  Allow Host PID:                               false
+  Allow Host IPC:                               false
+  Read Only Root Filesystem:                    false
+  Run As User Strategy: MustRunAsRange
+    UID:                                        <none>
+    UID Range Min:                              <none>
+    UID Range Max:                              <none>
+  SELinux Context Strategy: MustRunAs
+    User:                                       <none>
+    Role:                                       <none>
+    Type:                                       <none>
+    Level:                                      <none>
+  FSGroup Strategy: MustRunAs
+    Ranges:                                     <none>
+  Supplemental Groups Strategy: RunAsAny
+    Ranges:                                     <none>
+----
+
+The `restricted-v2` SCC explicitly denies everything except what it explicitly allows. The following settings define the allowed capabilities and security restrictions:
+
+* Default add capabilities: Set to `<none>`. It means that no capabilities are added to a pod by default.
+* Required drop capabilities: Set to `ALL`. This drops all the default Linux capabilities of a pod.
+* Allowed capabilities: `NET_BIND_SERVICE`. A pod can request this capability, but it is not added by default.
+* Allowed `seccomp` profiles: `runtime/default`. 
+
+For more information, see xref:../../../authentication/managing-security-context-constraints.adoc[Managing security context constraints].

modules/telco-security-command-line-host-access.adoc

@@ -0,0 +1,60 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-command-line-host-access_{context}"]
+= Command-line host access
+
+Direct access to a host must be restricted to avoid modifying the host or accessing pods that should not be accessed. For users who need direct access to a host, it is recommended to use an external authenticator, like SSSD with LDAP, to manage access. This helps maintain consistency across the cluster through the Machine Config Operator.
+
+[IMPORTANT]
+====
+Do not configure direct access to the root ID on any {product-title} cluster server.
+====
+
+You can connect to a node in the cluster using the following methods:
+
+Using debug pod:: This is the recommended method to access a node. To debug or connect to a node, run the following command:
++
+[source,terminal]
+----
+$ oc debug node/<worker_node_name>
+----
++
+After connecting to the node, run the following command to get access to the root file system:
++
+[source,terminal]
+----
+# chroot /host
+----
++
+This gives you root access within a debug pod on the node. For more information, see "Starting debug pods with root access".
+
+Direct SSH:: Avoid using the root user. Instead, use the core user ID (or your own ID). To connect to the node using SSH, run the following command:
++
+[source,terminal]
+----
+$ ssh core@<worker_node_name>
+----
++
+[IMPORTANT]
+====
+The core user ID is initially given `sudo` privileges within the cluster.
+====
++
+If you cannot connect to a node using SSH, see link:https://access.redhat.com/solutions/4073041[How to connect to {product-title} 4.x Cluster nodes using SSH bastion pod] to add your SSH key to the core user.
++
+After connecting to the node using SSH, run the following command to get access to the root shell:
++
+[source,terminal]
+----
+$ sudo -i
+----
+
+Console Access:: Ensure that consoles are secure. Do not allow direct login with the root ID, instead use individual IDs.
++
+[NOTE]
+====
+Follow the best practices of your organization for securing console access.
+====

modules/telco-security-evolu-nf-to-cnf.adoc

@@ -0,0 +1,18 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-evolution-of-nf-to-cnf_{context}"]
+= Evolution of Network Functions to CNFs
+
+Network Functions (NFs) began as Physical Network Functions (PNFs), which were purpose-built hardware devices operating independently. Over time, PNFs evolved into Virtual Network Functions (VNFs), which virtualized their capabilities while controlling resources like CPU, memory, storage, and network.
+
+As technology advanced further, VNFs transitioned to cloud-native network functions (CNFs). CNFs run in lightweight, secure, and scalable containers. They enforce stringent restrictions, including non-root execution and minimal host interference, to enhance security and performance.
+
+PNFs had unrestricted root access to operate independently without interference. With the shift to VNFs, resource usage was controlled, but processes could still run as root within their virtual machines. In contrast, CNFs restrict root access and limit container capabilities to prevent interference with other containers or the host operating system.
+
+The main challenges in migrating to CNFs are as follows:
+
+* Breaking down monolithic network functions into smaller, containerized processes.
+* Adhering to cloud-native principles, such as non-root execution and isolation, while maintaining telco-grade performance and reliability.

modules/telco-security-identity-prov-config.adoc

@@ -0,0 +1,24 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-identity-prov-config_{context}"]
+= Identity provider configuration
+
+Configuring an identity provider is the first step in setting up users on the cluster. You can manage groups at the organizational level by using an identity provider. 
+
+The identity provider can pull in specific user groups that are maintained at the organizational level, rather than the cluster level. This allows you to add and remove users from groups that follow your organization’s established practices.
+
+[NOTE]
+====
+You must set up a cron job to run frequently to pull any changes into the cluster.
+====
+
+You can use an identity provider to manage access levels for specific groups within your organization. For example, you can perform the following actions to manage access levels: 
+
+* Assign the `cluster-admin` role to teams that require cluster-level privileges.
+* Grant application administrators specific privileges to manage only their respective projects.
+* Provide operational teams with `view` access across the cluster to enable monitoring without allowing modifications.
+
+For information about configuring an identity provider, see "Understanding identity provider configuration".

modules/telco-security-infra.adoc

@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-infra_{context}"]
+= Telco-specific infrastructure
+
+Hardware requirements:: In telco networks, clusters are primarily built on bare-metal hardware. This means that the operating system (op-system-first) is installed directly on the physical machines, without using virtual machines. This reduces network connectivity complexity, minimizes latency, and optimizes CPU usage for applications.
+
+Network requirements:: Telco networks require much higher bandwidth compared to standard IT networks. Telco networks commonly use dual-port 25 GB connections or 100 GB Network Interface Cards (NICs) to handle massive data throughput. Security is critical, requiring encrypted connections and secure endpoints to protect sensitive personal data.

modules/telco-security-key-areas-for-cnf-deploy.adoc

@@ -0,0 +1,13 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-key-areas-for-cnf-deploy_{context}"]
+= Key areas for CNF deployment
+
+The cloud-native network function (CNF) deployment contains the following key areas:
+
+Core:: The first deployments of CNFs occurred in the core of the wireless network. Deploying CNFs in the core typically means racks of servers placed in central offices or data centers. These servers are connected to both the internet and the Radio Access Network (RAN), but they are often behind multiple security firewalls or sometimes disconnected from the internet altogether. This type of setup is called an offline or disconnected cluster.
+
+RAN:: After CNFs were successfully tested in the core network and found to be effective, they were considered for deployment in the Radio Access Network (RAN). Deploying CNFs in RAN requires a large number of servers (up to 100,000 in a large deployment). These servers are located near cellular towers and typically run as {sno} clusters, with the need for high scalability.

modules/telco-security-lifecycle-mgmnt.adoc

@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-lifecycle-mgmnt_{context}"]
+= Lifecycle management
+
+Upgrades are critical for security. When a vulnerability is discovered, it is patched in the latest z-stream release. This fix is then rolled back through each lower y-stream release until all supported versions are patched. Releases that are no longer supported do not receive patches. Therefore, it is important to upgrade {product-title} clusters regularly to stay within a supported release and ensure they remain protected against vulnerabilities.
+
+For more information about lifecycle management and upgrades, see "Upgrading a telco core CNF clusters".

modules/telco-security-linux-capabilities-overview.adoc

@@ -0,0 +1,31 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-linux-capabilities-overview_{context}"]
+= Linux capabilities
+
+Linux capabilities define the actions a process can perform on the host system. By default, pods are granted several capabilities unless security measures are applied. These default capabilities are as follows:
+
+* `CHOWN`
+* `DAC_OVERRIDE`
+* `FSETID`
+* `FOWNER`
+* `SETGID`
+* `SETUID`
+* `SETPCAP`
+* `NET_BIND_SERVICE`
+* `KILL`
+
+You can modify which capabilities that a pod can receive by configuring Security Context Constraints (SCCs).
+
+[IMPORTANT]
+====
+You must not assign the following capabilities to a pod:
+
+* `SYS_ADMIN`: A powerful capability that grants elevated privileges. Allowing this capability can break security boundaries and pose a significant security risk.
+* `NET_ADMIN`: Allows control over networking, like SR-IOV ports, but can be replaced with alternative solutions in modern setups.
+
+For more information about Linux capabilities, see link:https://man7.org/linux/man-pages/man7/capabilities.7.html[Linux capabilities] man page.
+====

modules/telco-security-pod-sec-in-kub-and-ocp.adoc

@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-pod-sec-in-kub-and-ocp_{context}"]
+= Advancement of pod security in Kubernetes and {product-title}
+
+Kubernetes initially had limited pod security. When {product-title} integrated Kubernetes, Red Hat added pod security through Security Context Constraints (SCCs). In Kubernetes version 1.3, `PodSecurityPolicy` (PSP) was introduced as a similar feature. However, Pod Security Admission (PSA) was introduced in Kubernetes version 1.21, which resulted in the deprecation of PSP in Kubernetes version 1.25.
+
+PSA also became available in {product-title} version 4.11. While PSA improves pod security, it lacks some features provided by SCCs that are still necessary for telco use cases. Therefore, {product-title} continues to support both PSA and SCCs.

modules/telco-security-rbac-overview.adoc

@@ -0,0 +1,39 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-rbac-overview_{context}"]
+= RBAC overview
+
+Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. 
+
+Cluster administrators can use the cluster roles and bindings to control who has various access levels to the {product-title} platform itself and all projects.
+
+Developers can use local roles and bindings to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.
+
+Authorization is managed using the following authorization objects:
+
+Rules:: Are sets of permitted actions on specific objects. For example, a rule can determine whether a user or service account can create pods. Each rule specifies an API resource, the resource within that API, and the allowed action.
+
+Roles:: Are collections of rules that define what actions users or groups can perform. You can associate or bind rules to multiple users or groups. A role file can contain one or more rules that specify the actions and resources allowed for that role. 
++
+Roles are categorized into the following types:
+
+* Cluster roles: You can define cluster roles at the cluster level. They are not tied to a single namespace. They can apply across all namespaces or specific namespaces when you bind them to users, groups, or service accounts.
+* Project roles: You can create project roles within a specific namespace, and they only apply to that namespace. You can assign permissions to specific users to create roles and role bindings within their namespace, ensuring they do not affect other namespaces.
+
+Bindings:: Are associations between users and/or groups with a role. You can create a role binding to connect the rules in a role to a specific user ID or group. This brings together the role and the user or group, defining what actions they can perform.
++
+[NOTE]
+====
+You can bind more than one role to a user or group.
+====
+
+For more information on RBAC, see "Using RBAC to define and apply permissions".
+
+[discrete]
+[id="telco-security-operational-rbac-considerations_{context}"]
+== Operational RBAC considerations
+
+To reduce operational overhead, it is important to manage access through groups rather than handling individual user IDs across multiple clusters. By managing groups at an organizational level, you can streamline access control and simplify administration across your organization.

modules/telco-security-replacing-kubeadmin-user.adoc

@@ -0,0 +1,52 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="telco-security-replacing-kubeadmin-user_{context}"]
+= Replacing the kubeadmin user with a cluster-admin user
+
+The `kubeadmin` user with the `cluster-admin` privileges is created on every cluster by default. To enhance the cluster security, you can replace the`kubeadmin` user with a `cluster-admin` user and then disable or remove the `kubeadmin` user.
+
+.Prerequisites
+
+* You have created a user with `cluster-admin` privileges.
+* You have installed the OpenShift CLI (`oc`).
+* You have administrative access to a virtual vault for secure storage.
+
+.Procedure
+
+. Create an emergency `cluster-admin` user by using the `htpasswd` identity provider. For more information, see "About htpasswd authentication".
+
+. Assign the `cluster-admin` privileges to the new user by running the following command:
++
+[source,terminal]
+----
+$ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>
+----
+
+. Verify the emergency user access:
+
+.. Log in to the cluster using the new emergency user.
+.. Confirm that the user has `cluster-admin` privileges by running the following command:
++
+[source,terminal]
+----
+$ oc whoami
+----
++
+Ensure the output shows the emergency user's ID.
+
+. Store the password or authentication key for the emergency user securely in a virtual vault. 
++
+[NOTE]
+====
+Follow the best practices of your organization for securing sensitive credentials.
+====
+
+. Disable or remove the `kubeadmin` user to reduce security risks by running the following command:
++
+[source,terminal]
+----
+$ oc delete secrets kubeadmin -n kube-system
+----

modules/telco-security-rhcos-overview.adoc

@@ -0,0 +1,33 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-rhcos-overview_{context}"]
+= {op-system-first}
+
+{op-system-first} is different from {op-system-base-full} in key areas. For more information, see "About {op-system}".
+
+From a telco perspective, a major distinction is the control of `rpm-ostree`, which is updated through the Machine Config Operator. 
+
+{op-system} follows the same immutable design used for pods in {product-title}. This ensures that the operating system remains consistent across the cluster. For information about {op-system} architecture, see "{op-system-first}".
+
+To manage hosts effectively while maintaining security, avoid direct access whenever possible. Instead, you can use the following methods for host management:
+
+* Debug pod
+* Direct SSHs
+* Console access
+
+Review the following {op-system} secruity mechanisms that are integral to maintaining host security: 
+
+Linux namespaces:: Provide isolation for processes and resources. Each container keeps its processes and files within its own namespace. If a user escapes from the container namespace, they could gain access to the host operating system, potentially compromising security.
+
+Security-Enhanced Linux (SELinux):: Enforces mandatory access controls to restrict access to files and directories by processes. It adds an extra layer of security by preventing unauthorized access to files if a process tries to break its confinement.
++
+SELinux follows the security policy of denying everything unless explicitly allowed. If a process attempts to modify or access a file without permission, SELinux denies access. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/using_selinux/index#introduction-to-selinux_getting-started-with-selinux[Introduction to SELinux].
+
+Linux capabilities:: Assign specific privileges to processes at a granular level, minimizing the need for full root permissions. For more information, see "Linux capabilities".
+
+Control groups (cgroups):: Allocate and manage system resources, such as CPU and memory for processes and containers, ensuring efficient usage. As of {product-title} 4.16, there are two versions of cgroups. cgroup v2 is now configured by default.
+
+CRI-O:: Serves as a lightweight container runtime that enforces security boundaries and manages container workloads.

modules/telco-security-sec-accounts-overview.adoc

@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-sec-accounts-overview_{context}"]
+= Security accounts overview
+
+A service account is an {product-title} account that allows a component to directly access the API. Service accounts are API objects that exist within each project.
+Service accounts provide a flexible way to control API access without sharing a regular user's credentials. 
+
+You can use service accounts to apply role-based access control (RBAC) to pods. By assigning service accounts to workloads, such as pods and deployments, you can grant additional permissions, such as pulling from different registries. This also allows you to assign lower privileges to service accounts, reducing the security footprint of the pods that run under them.
+
+For more information about service accounts, see "Understanding and creating service accounts".
+

modules/telco-security-sec-considerations-telco.adoc

@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="telco-security-sec-considerations-telco_{context}"]
+= Security considerations for telco CNFs
+
+Telco workloads handle vast amounts of sensitive data and demand high reliability. A single security vulnerability can lead to broader cluster-wide compromises. With numerous components running on a {sno} cluster, each component must be secured to prevent any breach from escalating. Ensuring security across the entire infrastructure, including all components, is essential to maintaining the integrity of the telco network and avoiding vulnerabilities.
+
+The following key security features are essential for telco:
+
+* Security Context Constraints (SCCs): Provide granular control over pod security in the OpenShift clusters.
+* Pod Security Admission (PSA): Kubernetes-native pod security controls.
+* Encryption: Ensures data confidentiality in high-throughput network environments.