// 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>`
|===


