Red Hat OpenShift Service on AWS security FAQ

Site reliability engineer (SRE) access for Red Hat OpenShift Service on AWS

How do SREs access my Red Hat® OpenShift® Service on AWS cluster by default?

Answer: SREs access Red Hat OpenShift Service on AWS private clusters using an encrypted HTTP connection. Connections are permitted only from a security-safe Red Hat network using either an IP allowlist or a private cloud provider link.

How does Amazon Web Service (AWS) PrivateLink change the way SREs access my Red Hat OpenShift Service on AWS cluster?

Answer: The Red Hat managed infrastructure that creates AWS PrivateLink clusters is hosted on private subnets. The connection between Red Hat and the customer-provided infrastructure is created through AWS PrivateLink virtual private cloud (VPC) endpoints.

What permissions do I need to run an OpenShift Service on AWS cluster?

Answer: The recommended implementation is using the AWS Security Token Service (STS). After the cluster is created, an identity provider must be configured so that the accesses will be validated by it. This is a list of supported providers.

It is a best practice for the OpenShift Service on AWS cluster to be hosted in an AWS account within an AWS organizational unit (OU). A service control policy (SCP) is created and applied to the AWS OU that manages what services the AWS sub-accounts are permitted to access. The SCP applies only to available permissions within a single AWS account for all AWS sub-accounts within the OU. It is also possible to apply a SCP to a single AWS account. All other accounts in the customer’s AWS organizations are managed in whatever manner the customer requires. Red Hat SREs will not have control over SCPs within AWS organizations. 

In the case of customers who, despite the recommendation, have not yet chosen to build OpenShift Service on AWS clusters in STS mode, Red Hat must have the administrator access policy applied to the administrator role at all times.

To deploy an OpenShift Service on AWS cluster that uses the AWS Security Token Service (STS), customers must create the following AWS Identity Access Management (IAM) resources:

  • Specific account-wide identity and access management (IAM) roles and policies that provide the STS permissions required for OpenShift Service on AWS support, installation, control plane, and compute functionality. This includes account-wide operator policies. These are provided by OpenShift Service on AWS command-line interface (CLI).
  • Cluster-specific operator IAM roles that permit the OpenShift Service on AWS cluster operators to carry out core OpenShift functionality. These are provided by the OpenShift Service on AWS CLI.
  • An OpenID Connect (OIDC) provider that the cluster operators use to authenticate. Also provided by Red Hat OpenShift Service on AWS CLI.
  • If OpenShift Service on AWS is deployed by using Red Hat OpenShift Cluster Manager, these additional resources must be created:
    • An ocm-role to complete the installation on the cluster.
    • A user role without any permissions to verify the AWS account identity.
    • Both are provided by OpenShift Service on AWS CLI.

STS is the recommended credential mode because of the enhanced security it provides.

What is the IAM policy for implementations with STS and for those without it?

Answer: This is the reference for IAM policies when using STS, which is the recommended implementation.

In the case that a customer is still not using STS, Red Hat must have the administrator access policy applied to the administrator role at all times. Red Hat is responsible for creating and managing IAM policies, IAM users, and IAM roles. Review  a description of the administratoraccess policy.

What level of access do SREs have to my OpenShift Service on AWS cluster? Can they access my applications and data?

Answer: An SRE adheres to the principle of least privilege when accessing OpenShift Service on AWS and AWS components. There are 4 basic categories of manual SRE access:

  • SRE access through the Red Hat Portal with normal two-factor authentication and no privileged elevation.
  • SRE access through the Red Hat corporate single-sign on (SSO) with normal two-factor authentication and no privileged elevation.
  • Red Hat OpenShift elevation, which is a manual elevation using Red Hat SSO. Access is audited.
  • AWS access or elevation, which is a manual elevation for AWS console or CLI access. Access is limited to 60 minutes and is fully audited.

How do SREs access my cluster?

Answer: Red Hat personnel do not access AWS accounts in the course of routine OpenShift Service on AWS operations. For emergency troubleshooting purposes, Red Hat SREs have well-defined and auditable procedures to access cloud infrastructure accounts.

SREs generate a short-lived AWS access token for a reserved role using the AWS Security Token Service (STS). Access to the STS token is audit-logged and traceable back to individual users. Both STS and non-STS clusters use the AWS STS service for SRE access. For non-STS clusters, the BYOCAdminAccess role has the administrator access IAM policy attached, and this role is used for administration. For STS clusters, the ManagedOpenShift-Support-role has the ManagedOpenShift-Support-access policy attached, and this role is used for administration.

New SRE user access requires management approval. Separated or transferred SRE accounts are removed as authorized users through an automated process. Additionally, the SRE performs periodic access review, including management sign-off of authorized user lists

Are there SRE audit logs for what was done or accessed? How do we get access to these?

Answer: SREs must authenticate as individuals to ensure auditability. All authentication attempts are logged to a Security Information and Event Management (SIEM) system.

Where are the SREs located?

Answer: Review the Red Hat subprocessor list for information about SRE locations.

Learn how to set up a private OpenShift cluster on AWS and PrivateLink with our detailed architecture guide:

Red Hat OpenShift Service on AWS implementation guide >>

Customer process and tooling

InfoSec requires us to install <insert traditional security tool> on all servers. Can I install these on OpenShift Service on AWS hosts?

Answer: This is not supported. See policies and service definitions for details.

Can we get access to the SRE logging system and forward to our centralized logging solution?

Answer: OpenShift Service on AWS provides optional integrated log forwarding to Amazon CloudWatch.

What steps are taken to harden the OpenShift Service on AWS cluster?

Answer: Apart from the use of load balancers and PrivateLink, each OpenShift Service on AWS cluster is protected by a security-focused network configuration using firewall rules for AWS security groups. OpenShift Service on AWS customers are also protected against distributed denial-of-service (DDoS) attacks with AWS Shield Standard.

Red Hat performs periodic penetration tests against OpenShift Service on AWS. Tests are performed by an independent internal team by using industry standard tools and best practices. Any issues that may be discovered are prioritized based on severity. Any issues found belonging to open source projects are shared with the community for resolution.

Explore the power of and simplicity of OpenShift on AWS with self-paced learning paths.

Learning path for operations and sysadmins:

Getting started with Red Hat OpenShift Service on AWS

New to Red Hat OpenShift Service on AWS? Get started with a self-paged video learning path:

Red Hat OpenShift Service on AWS (ROSA) explained