diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml index 31766671ca7a..8fb832dd17b5 100644 --- a/_topic_maps/_topic_map_rosa.yml +++ b/_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{OCP} FedRAMP Rev5 Secure Configuration Guidance + File: rosa-fedramp-security-config --- Name: Install ROSA Classic clusters Dir: rosa_install_access_delete_clusters @@ -1000,14 +1002,14 @@ Topics: Dir: routes Distros: openshift-rosa Topics: - - Name: Creating basic routes - File: creating-basic-routes - - Name: Securing routes - File: securing-routes - - Name: Configuring Routes - File: nw-configuring-routes - - Name: Securing routes through ingress objects - File: creating-advanced-routes + - Name: Creating basic routes + File: creating-basic-routes + - Name: Securing routes + File: securing-routes + - Name: Configuring Routes + File: nw-configuring-routes + - Name: Securing routes through ingress objects + File: creating-advanced-routes --- Name: Building applications Dir: applications diff --git a/modules/rosa-fedramp-accounts-config.adoc b/modules/rosa-fedramp-accounts-config.adoc new file mode 100644 index 000000000000..28668cf7c7ce --- /dev/null +++ b/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 ` + +|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 --verb= --resource=` + +|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 ` + +|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 -n ` +* Grant permissions: `oc adm policy add-role-to-user system:serviceaccount::` + +|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 -n ` + +|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 -n ` + +|Grant namespace view roles +|Assign view capabilities for read-only namespace and workload access. +|`oc adm policy add-role-to-user view -n ` + +|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 --verb= --resource= -n ` + +|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 -n ` + +|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 -n ` +* Or grant role: `oc adm policy add-role-to-user -z -n ` + +|Extract service account tokens +|Use localized automated service tokens safely for external system or pipeline authentication actions. +|`oc create token -n ` +|=== + +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 --cert= --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 --hard=cpu=10,memory=20Gi,persistentvolumeclaims=5 -n ` + +|View quota usage +|Audit resource allocation to ensure that project bounds are functioning correctly and limits are not exhausted. +|`oc describe quota -n ` + +|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 -n ` + +|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 -z -n ` + +|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 ` +|=== + +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 ` +* Remove namespace roles: `oc adm policy remove-role-from-user -n ` + +|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 ` + +|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 ` +* Or remove Identity link: `oc delete identity :` + +|Remove service account access +|Permanently delete namespace-scoped automated service accounts that are no longer required for active operations. +|`oc delete serviceaccount -n ` + +|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 --from-literal=key=value -n ` + +|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 --from-file= -n ` + +|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 --docker-server= --docker-username= --docker-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 --for=pull -n ` + +|Manage monitoring and logging access +|Namespace administrators access localized application logs and metrics within assigned boundaries, preventing cross-namespace data visibility. +|`oc logs -n ` + +|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 ` + +|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 -n ` +|=== + + diff --git a/modules/rosa-fedramp-overview.adoc b/modules/rosa-fedramp-overview.adoc new file mode 100644 index 000000000000..0e8de95a4288 --- /dev/null +++ b/modules/rosa-fedramp-overview.adoc @@ -0,0 +1,67 @@ +// Module included in the following assemblies: +// +// * rosa_govcloud/rosa-fedramp-security-config.adoc + +:_mod-docs-content-type: CONCEPT + +[id="rosa-fedramp-overview_{context}"] += Learn about FedRAMP Rev5 Secure Configuration Guidance (SCG) requirements + +[role="_abstract"] +Federal Risk and Authorization Management Program (FedRAMP) Rev5 Secure Configuration Guidance (SCG) gives you complete coverage for all your administrative tasks. {product-title} completes all the SCG requirements for you, so you can focus on configuring your accounts to your needs. + +To learn more about the about the cloud service offering requirements that {product-title} has already completed for you, see the following table: + +.Cloud service offering requirement +[cols="1,2,3",options="header"] +|=== +|Requirement +|Description +|{OCP} Solution + +|SCG-CSO-RSC (Recommended Secure Configuration) +|Providers must create, keep, and make available recommendations for securely configuring their cloud services. +|Delivers comprehensive security configuration documentation covering all top-level administrative and privileged accounts. + +|SCG-CSO-AUP (Authorization Package) +|Providers must include instructions in the FedRAMP authorization package that explain how to obtain and use the SCG. +|Publishes security configuration guidance on docs.redhat.com with indexed navigation, searchable table of contents, and sequential implementation procedures for all administrative security controls. + +|SCG-CSO-PUB (Public Availability) +|Providers should make the SCG publicly available, enabling agency review before any procurement and implementation decisions. +|Publishes security configuration guidance on docs.redhat.com, accessible to anyone with a free Red Hat account (no subscription required). Federal procurement officers can review security implementation requirements during vendor evaluation without purchasing a subscription. + +|SCG-CSO-SDF (Secure Default Settings) +|Providers SHOULD set all settings to their recommended secure defaults at service provisioning, reducing customer configuration burden. +|Deploys clusters with hardened default security configurations. +|=== + +In addition to the requirements, you have the option for enhanced capabilities based on your specific needs. To learn more, see the following table: + +.Enhanced capabilities +[cols="1,2,3",options="header"] +|=== +|Recommendation +|Description +|Red Hat OpenShift Solution + +|SCG-ENH-CMP (Comparison) +|Comparison Capability: Providers should offer capability to compare all current settings against the recommended settings identified in the SCG. +|Gives the Compliance Operator for continuous configuration assessment against National Institute of Standards and Technology (NIST) 800-53 security control baselines. Executes automated ComplianceScan resources comparing active cluster settings to FedRAMP Moderate and High profiles. + +|SCG-ENH-EXP (Export) +|Export Capability: Providers should offer capability to export all security settings in machine-readable format, such as: JSON, XML, or CSV. +|Exposes comprehensive REST APIs for programmatic security configuration management through OAuth 2.0 authentication. Supplies official client libraries supporting Python, Go, Java, and JavaScript development environments. + +|SCG-ENH-API (Application Programming Interface) +|API Capability: Providers should offer capability to view and adjust security settings through the API and management console. +|Enables complete programmatic control over all security policies and configurations. + +|SCG-ENH-MRG (Machine-Readable Guidance) +|Machine-Readable Guidance: Providers should also give the SCG in machine-readable format that automated compliance processes can ingest. +|Generates machine-parsable compliance assessment artifacts conforming to Open Security Controls Assessment Language (OSCAL) schema standards through the compliance operator. + +|SCG-ENH-VRH (Versioning and Release History) +|Versioning and Release History: Providers should give versioning and release history of the SCG as the recommended settings change. +|Maintains version-controlled documentation tracking security configuration changes across platform releases. +|=== \ No newline at end of file diff --git a/rosa_govcloud/rosa-fedramp-security-config.adoc b/rosa_govcloud/rosa-fedramp-security-config.adoc new file mode 100644 index 000000000000..c3716291cd68 --- /dev/null +++ b/rosa_govcloud/rosa-fedramp-security-config.adoc @@ -0,0 +1,35 @@ +:_mod-docs-content-type: ASSEMBLY +include::_attributes/attributes-openshift-dedicated.adoc[] +:context: rosa-fedramp-security-config +[id="rosa-fedramp-security-config"] += Red{nbsp}Hat {OCP} FedRAMP Rev5 Secure Configuration Guidance + +toc::[] + +[role="_abstract"] +Complete the Red{nbsp}Hat {OCP} Federal Risk and Authorization Management Program (FedRAMP) Rev5 Secure Configuration Guidance (SCG) requirements so that you have clear guidance on how to securely configure and operate your cloud services. Use the SCG to supplement the Customer Responsibilities Matrix (CRM), giving you actionable steps for securing administrative accounts and system configurations. + +When you use SCG on a Red{nbsp}Hat {OCP}, you have the following guidance and capabilities: + +* Administrative Account Protection: Comprehensive guidance for securing administrative accounts with dedicated-admin privileges, implementing role-based access control (RBAC), configuring identity providers, and managing privileged access with audit logging and session controls. +* Machine-Readable Formats: Configuration export capabilities in YAML, JSON, and Open Security Controls Assessment Language (OSCAL) formats through the Compliance Operator, enabling automated compliance verification and configuration management. +* API-Driven Configuration: Full programmatic access to all security settings through Kubernetes and OpenShift REST APIs, with official SDKs for many programming languages supporting infrastructure-as-code workflows. + +Before you learn guidance for your different administrative roles, complete the following foundational security configuration actions: + +* Configure identity providers by setting up Open Authorization (OAuth) integration with your selected enterprise directory service: Lightweight Directory Access Protocol (LDAP), Active Directory, or OpenID Connect (OIDC) provider. After configuring your enterprise identity provider, delete the temporary htpasswd identity provider created by `rosa create admin` to comply with FedRAMP identity requirements. +* Implement RBAC controls by applying role-based access control following the principle of least privilege. Create custom roles for specific administrative functions within the dedicated-admin scope. +* Enable compliance scanning by installing and configuring the Compliance Operator to continuously monitor your cluster against FedRAMP Moderate or High baselines and automatically detect configuration drift. +* Configure audit logging by setting the API server audit profile to `WriteRequestBodies` or higher to capture comprehensive logs of all administrative actions for compliance and forensic purposes. +* Review security context constraints to ensure workloads use the most restrictive SCC possible. The restricted-v2 SCC is recommended, and you should create custom SCCs only when necessary with minimal required privileges. + +include::modules/rosa-fedramp-overview.adoc[leveloffset=+1] +include::modules/rosa-fedramp-accounts-config.adoc[leveloffset=+1] + +[role="_additional-resources"] +[id="additional-resources_{context}"] +== Additional resources + +* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4[Red Hat OpenShift Service on AWS (ROSA) Documentation] +* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/authentication_and_authorization/index[ROSA Authentication and Authorization Guide] +* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/security_and_compliance/index[ROSA Security and Compliance Guide] \ No newline at end of file