added fedramp sec config guide

_topic_maps/_topic_map_rosa.yml

@@ -231,6 +231,8 @@ Topics:
   File: rosa-govcloud-account-management
 - Name: Installing a Red Hat OpenShift Service on AWS (classic architecture) cluster in AWS GovCloud
   File: rosa-install-govcloud-cluster
+- Name: Red Hat OpenShift Service on AWS FedRAMP Rev5 Secure Configuration Guidance
+  File: rosa-fedramp-security-config
 ---
 Name: Install ROSA Classic clusters
 Dir: rosa_install_access_delete_clusters
@@ -1005,7 +1007,7 @@ Topics:
         File: securing-routes
       - Name: Configuring Routes
         File: nw-configuring-routes
-      - Name: Creating advanced Routes
+      - Name: Creating advanced routes
         File: creating-advanced-routes
 ---
 Name: Building applications

modules/rosa-fedramp-accounts-config.adoc

@@ -0,0 +1,240 @@
+// Module included in the following assemblies:
+//
+// * rosa_govcloud/rosa-fedramp-security-config.adoc
+
+:_mod-docs-content-type: REFERENCE
+
+[id="rosa-fedramp-accounts-config_{context}"]
+= Red{nbsp}Hat {OCP} FedRAMP Rev5 Secure Configuration Guidance for top-level administrative and privileged accounts
+
+[role="_abstract"]
+{product-title} gives you comprehensive frameworks to find roles, isolation boundaries, and operational functions for top-level administrative or privileged accounts. These frameworks apply within a Red{nbsp}Hat {OCP} Federal Risk and Authorization Management Program (FedRAMP) Rev5 Secure Configuration Guidance (SCG) environment.
+
+The guidance you receive addresses the SCG-CSO-RSC (Cloud Service Offering - Recommended Secure Configuration) requirement, including both cluster-wide top-level administrative accounts and namespace-scoped privileged accounts. The parameters in both administrative and privilege accounts help you deploy, operate, decommission, and secure access among your configurations.
+
+For the most up-to-date account features and structural prerequisites, review the official Red{nbsp}Hat {OCP-short} documentation page for your active deployment service. Your browser must have JavaScript enabled to access and interact with the documentation portal for link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.22[Red Hat OpenShift Container Platform]. 
+
+[IMPORTANT]
+====
+* To access the cluster for the first time, create a temporary administrative user with the `rosa create admin` command. The command outputs login credentials to your terminal.
+* Copy and store these credentials. The credentials are not automatically saved to the disk.
+* To comply with FedRAMP identity boundaries, use this temporary account primarily to configure enterprise identity providers, then delete the temporary admin user.
+====
+
+For guidance and context on different actions you can take in your top level administrative account, see the following table:
+
+[NOTE]
+====
+In {product-short}, you can perform administrative tasks using either the `dedicated-admin` or `cluster-admin` role. Use the `dedicated-admin` role as your preferred choice because it provides administrative permissions for managing namespaces and workloads without potentially disrupting your cluster operations. Since the `cluster-admin` role is the highest level of privilege that you could have, the `cluster-admin` can unintentionally get your cluster into an unsupportable state.
+====
+
+.Actions and benefits for account provisioning and access setup 
+[cols="1,2,2",options="header"]
+|===
+|Action
+|Benefit
+|Command
+
+|Grant dedicated-admin privileges
+|Grant administrative access to users by adding them to the `dedicated-admins` group. This provides elevated permissions for managing user namespaces, assigning security context constraints, and configuring identity providers, while control plane management remains with Red Hat SRE.
+|`oc adm groups add-users dedicated-admins <username>`
+
+|Verify dedicated-admin membership
+|Ensure that administrative users are correctly assigned to the `dedicated-admins` group.
+|`oc get groups dedicated-admins -o yaml`
+
+|Configure multifactor authentication (MFA)
+|Enforce MFA through the configured identity provider. OpenID Connect and SAML providers support MFA enforcement at the identity provider layer.
+|Managed directly at the enterprise Identity Provider (IdP) layer.
+
+|Configure cluster role-based access control
+|Implement least privilege access by creating custom cluster roles with specific permissions within the scope allowed by dedicated-admin privileges. Define custom cluster roles for namespace-scoped resource management.
+|`oc create clusterrole <role_name> --verb=<verbs> --resource=<resources>`
+
+|Bind custom roles to users
+|Ensures your users only have the capabilities that you want them to have.
+|`oc adm policy add-cluster-role-to-user <role_name> <username>`
+
+|Configure service account
+|Create service accounts for automated processes and CI/CD pipelines. Service accounts authenticate using tokens rather than user credentials.
+a|
+* Create service account: `oc create serviceaccount <service_account_name> -n <namespace>`
+* Grant permissions: `oc adm policy add-role-to-user <role> system:serviceaccount:<namespace>:<service_account_name>`
+
+|View assigned projects
+|Verify that a privileged namespace administrator has clear visibility into the specific isolated projects they need to manage.
+|`oc get projects`
+
+|Assign specialized administrative roles
+|Assign users to specialized administrative roles for specific cluster operations. Common roles include `cluster-reader` (read-only cluster metadata), `registry-admin` (internal registry control), and `storage-admin` (persistent volumes). These roles provide targeted permissions without requiring full dedicated-admin group membership.
+|Handled through specialized cluster role attachments.
+
+|Grant namespace administrative roles
+|Assign administrative roles to users for specific namespaces. This grants permissions to view/edit all namespace resources, manage secrets, bind local roles, and configure network policies within that project scope.
+|`oc adm policy add-role-to-user admin <username> -n <namespace>`
+
+|Grant namespace edit roles
+|Assign edit capabilities to user roles for direct deployment and workload modification permissions without exposing local role binding control.
+|`oc adm policy add-role-to-user edit <username> -n <namespace>`
+
+|Grant namespace view roles
+|Assign view capabilities for read-only namespace and workload access.
+|`oc adm policy add-role-to-user view <username> -n <namespace>`
+
+|Create custom namespace roles
+|Define local roles with specific permission sets restricted to particular resources and verbs aligned to narrow organizational requirements.
+|`oc create role <role_name> --verb=<get,list,watch> --resource=<pods,services> -n <namespace>`
+
+|Bind custom roles to namespace users
+|Bind custom localized roles to users to guarantee that namespace-scoped personnel only have targeted privileges inside that specific boundary.
+|`oc adm policy add-role-to-user <role_name> <username> -n <namespace>`
+
+|Grant service account privileges (Namespace)
+|Configure service accounts with localized, privileged permissions for automated application workflows, ensuring minimum access needed for operation.
+a|
+* Create service account: `oc create sa <service_account_name> -n <namespace>`
+* Or grant role: `oc adm policy add-role-to-user <role> -z <service_account_name> -n <namespace>`
+
+|Extract service account tokens
+|Use localized automated service tokens safely for external system or pipeline authentication actions.
+|`oc create token <service_account_name> -n <namespace>`
+|===
+
+For guidance on operating your top level administrative accounts, see the following table: 
+
+.Guidance on operating administrative and privileged accounts
+[cols="1,2,2",options="header"]
+|===
+|Action
+|Benefit
+|Command
+
+|Manage certificates
+|Replace default API server certificates with custom certificates issued by an organizational certificate authority. Create a secret containing the certificate and key. Update the API server configuration to reference the custom certificate secret. Certificate rotation occurs automatically when you update the secret with a new certificate.
+|`oc create secret tls <secret_name> --cert=<path/to/cert> --key=<path/to/key> -n openshift-config`
+
+|Monitor administrative accounts
+|Review cluster events and administrative activities. Query audit logs for specific user activities. Monitor role binding changes indicating privilege escalation attempts.
+|`oc get events --all-namespaces`
+
+|Grant namespace administration tasks
+|Allow namespace administrators to handle project-scoped operations: deploying workloads, managing secrets, applying resource quotas, defining network restrictions, and binding local access.
+|Executed through namespace-scoped `oc` subcommands.
+
+|Manage resource quotas
+|Configure hard infrastructure resource quotas limiting localized namespace consumption across CPU, memory, storage requests, and PVC limits.
+|`oc create quota <quota_name> --hard=cpu=10,memory=20Gi,persistentvolumeclaims=5 -n <namespace>`
+
+|View quota usage
+|Audit resource allocation to ensure that project bounds are functioning correctly and limits are not exhausted.
+|`oc describe quota -n <namespace>`
+
+|Configure network policies
+|Create namespace-scoped `NetworkPolicy` objects to control pod-to-pod traffic within your projects. Implement default-deny policies that block all traffic except explicitly allowed connections. Cluster-wide network security is managed by Red Hat SRE.
+|`oc create -f <networkpolicy.yaml> -n <namespace>`
+
+|Assign security context constraints
+|Namespace administrators can assign pre-defined security context constraints (SCCs) to service accounts within their projects. Red Hat SRE manages the global SCC definitions (such as `restricted-v2` and `privileged`). Users with dedicated-admin privileges can assign allowed SCCs to their service accounts to grant specific pod security capabilities.
+|`oc adm policy add-scc-to-user <scc_name> -z <service_account_name> -n <namespace>`
+
+|View SCC assignments
+|Verify that global or namespace SCC privileges match accurately to the correct infrastructure components and local service accounts.
+a|
+* Global view: `oc get scc`
+* Namespace verification: `oc get scc -o yaml \| grep -A 5 <service_account_name>`
+|===
+
+For guidance on decommissioning your top level administrative accounts, see the following table:
+
+.Guidance on decommissioning your administrative and privileged accounts
+[cols="1,2,2",options="header"]
+|===
+|Action
+|Benefit
+|Command
+
+|Remove user access
+|Remove administrative or namespace role assignments from departing personnel to prevent residual access.
+a|
+* Remove dedicated-admin privileges: `oc adm groups remove-users dedicated-admins <username>`
+* Remove namespace roles: `oc adm policy remove-role-from-user <role> <username> -n <namespace>`
+
+|List role bindings
+|Run global searches across all cluster and project boundaries to verify the complete, absolute removal of the targeted user's permissions.
+|`oc get rolebindings,clusterrolebindings --all-namespaces -o wide \| grep <username>`
+
+|Remove identity provider entries
+|Clean up the internal cluster user identity mapping registries thoroughly when you skip roles.
+a|
+* Remove User object: `oc delete user <username>`
+* Or remove Identity link: `oc delete identity <identity_provider_name>:<username>`
+
+|Remove service account access
+|Permanently delete namespace-scoped automated service accounts that are no longer required for active operations.
+|`oc delete serviceaccount <service_account_name> -n <namespace>`
+
+|Verify service account deletion
+|Auditing step ensures no unlinked automated keys remain active, which effectively blocks associated pods from authenticating unauthorized API calls.
+|Monitored by querying namespace resources post-deletion.
+
+|Transfer resource ownership
+|Audit resources created by the departing administrator to transfer ownership. Review projects, security policies, and configurations requiring ownership reassignment to active administrators.
+|Managed through resource metadata modification and project reassignment.
+|===
+
+For guidance on security related settings, see the following table:
+
+.Guidance on setting security for your administrative and privileged accounts
+[cols="1,2,2",options="header"]
+|===
+|Action
+|Benefit
+|Command
+
+|Install the Compliance Operator
+| Automate configuration auditing and compliance monitoring. The Compliance Operator scans cluster infrastructure against National Institute of Standards and Technology (NIST) 800-53 controls required for FedRAMP. Create `ComplianceSuite` resources to schedule assessments that detect configuration drift and generate remediation recommendations. Visualize compliance results in the {OCP-short} console or integrate with Red Hat Advanced Cluster Security (RHACS) dashboard for centralized compliance tracking and correlation with security findings.
+|Handled through OperatorHub, then create `ComplianceSuite` resources targeting FedRAMP profiles, `ocp4-moderate` or `ocp4-high`. View results in {OCP-short} console under `Compliance` or in ACS dashboard.
+
+
+|Configure image security
+|Configure image signature verification enforcing signed container images for deployment. Create `ImageContentSourcePolicy` resources defining trusted registries and integrate external vulnerability scanners.
+|Applied through global cluster-wide security policies.
+
+|Set pod security standards
+|Enforce runtime isolation constraints across namespaces. Restricts pod capabilities regarding host namespaces, root privileges, volume types, and root filesystems to isolate tenant workloads.
+|Handled through platform admission controllers and namespace labels.
+
+|Manage secrets from literal values
+|Namespace administrators create and store sensitive key/value configuration data locally. Secrets are base64 encoded but require cluster-wide etcd encryption to be fully encrypted at rest.
+|`oc create secret generic <secret_name> --from-literal=key=value -n <namespace>`
+
+|Manage secrets from files
+|Generate local secrets using complete files to mount directly into applications as environment variables or secure volume mounts.
+|`oc create secret generic <secret_name> --from-file=<path/to/file> -n <namespace>`
+
+|Pull image secrets
+|Safely store and configure private registry authentication tokens by creating dedicated `docker-registry` credentials within the project.
+|`oc create secret docker-registry <secret_name> --docker-server=<registry-url> --docker-username=<username> --docker-password=<password>`
+
+|Link secrets to service accounts
+|Inject private registry pull credentials directly into namespace service accounts to allow automated image validation and pull authentication.
+|`oc secrets link <service_account_name> <secret_name> --for=pull -n <namespace>`
+
+|Manage monitoring and logging access
+|Namespace administrators access localized application logs and metrics within assigned boundaries, preventing cross-namespace data visibility.
+|`oc logs <pod-name> -n <namespace>`
+
+|Review installed operators
+|Inspect local, namespace-scoped operators running within the project from OperatorHub, verifying their management permissions are constrained strictly to that namespace.
+|`oc get csv -n <namespace>`
+
+|View Security Context Constraints (SCCs)
+|Review available security context constraints that control pod security capabilities. Red Hat SRE manages SCC definitions. The default `restricted-v2` SCC applies to pods without explicit SCC specification. The `privileged` SCC grants host-level access and is restricted to Red Hat-managed infrastructure components. Namespace administrators can assign pre-defined SCCs to their service accounts.
+|`oc get scc`
+
+|Define network policies
+|Create namespace-scoped `NetworkPolicy` resources to control pod-to-pod communication and external access within your projects. Implement default-deny policies requiring explicit allow rules for permitted traffic. Cluster-wide network security is managed by Red Hat SRE.
+|`oc create -f <networkpolicy.yaml> -n <namespace>`
+|===
+
+