This is a cache of https://docs.openshift.com/dedicated/3/product_security/recommendations_for_customers/restrict_access.html. It is a snapshot of the page at 2024-11-24T05:04:40.602+0000.
Restrict Access - Recommendations for Customers | Security | OpenShift Dedicated 3
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Restrict Access

Users and Group Access

Learn about assigning user and group access.

Managing Role-based Access Control (RBAC)

Roles can be used to grant various levels of access both cluster-wide as well as at the project-scope. Users and groups can be associated with, or bound to, multiple roles at the same time. You can view details about the roles and their bindings using the oc describe command.

Dedicated Administrator Role

As a dedicated administrator of an OpenShift Dedicated cluster, your account has increased permissions and access to all user-created projects. This role binds you to the dedicated-project-admin for any new projects that are created by users in the cluster. At the project level, an administrator of an OpenShift Dedicated cluster can perform all actions that a project administrator can perform and, in addition, can set resource quotas and limit ranges for the project. As the dedicated-cluster-admin, you can view but not manage cluster roles. However, you can manage cluster role bindings and manage local roles and bindings. At the cluster level, a dedicated-admin can:

  • Manage users and groups.

  • Manage roles and bindings.

  • Manage authorization.

  • View certain cluster-level resources including events, nodes, persistent volumes, and security context constraints.

  • Create daemon sets, which ensure that nodes run a copy of a pod.

Users with the admin default cluster role bound locally can manage roles and bindings for that project.

To view cluster roles as dedicated-admin for namespace test1234, run:

$ oc get clusterrolebinding.rbac -n test1234

To view local roles for the test1234 namespace:

$ oc get rolebinding.rbac -n test1234

See Administering an OpenShift Dedicated Cluster for more information.

Service Accounts

A service account is a special user account that an application or service uses to interact with the operating system. Services use the service accounts to log on and make changes to the operating system or the configuration. Actions that the service can perform are controlled with permissions. Every service account has an associated user name that can be granted roles, just like a regular user. The user name is derived from its project and name:

system:serviceaccount:<project>:<name>

To allow all service accounts in the managers project to edit resources in the test1234 project, run:

$ oc policy add-role-to-group edit system:serviceaccount:managers -n test1234

The system ensures that service accounts always have an API token and registry credentials. The generated API token and registry credentials do not expire, but they can be revoked by deleting the secret. When the secret is deleted, a new one is automatically generated to take its place.

In addition to providing API credentials, a pod’s service account determines which secrets the pod is allowed to use. Pods use secrets in two ways:

  • Image pull secrets, providing credentials used to pull images for the pod’s containers.

  • Mountable secrets, injecting the contents of secrets into containers as files.

To allow a secret to be used as an image pull secret by a service account’s pods, run:

$ oc secrets link --for=pull <serviceaccount-name> <secret-name>

To allow a secret to be mounted by a service account’s pods, run:

$ oc secrets link --for=mount <serviceaccount-name> <secret-name>

See Configuring Service Accounts for more information.

Service Serving certificate Secrets: Application-level Public Key Infrastructure

OpenShift Dedicated features an application-level public key infrastructure (PKI). This PKI manages certificates generated with the service serving certificate secret feature. The Root CA files for this PKI are stored on master nodes under /etc/origin/master/service.

Service serving certificate secrets are intended to support complex middleware applications that need out-of-the-box certificates. To secure communication to your service, have the cluster generate a signed serving certificate/key pair into a secret in your namespace. The certificate and key are in Privacy-Enhanced Mail (PEM) format, stored in tls.crt and tls.key respectively. The certificate/key pair is automatically replaced when it gets close to expiration. The signature algorithm for this feature is x509.SHA256WithRSA. To manually rotate the certificate/key pair, delete the generated secret and a new certificate will be created. See Service Serving certificate Secrets for more information.

Restricting Network Access

Traffic inbound to the cluster can be restricted at the platform level. If using a VPN connection or a VPC peer, access to the cluster can be restricted so that only internal traffic is accepted. Route-specific IP whitelisting can also be implemented.

Routes

See the Routes topic for an overview of routes, including route-specific annotations and IP whitelisting.

Custom Domains

To use custom domain names for your application routes, see Configure your application routes. When application owners choose to create custom domains and associated routes, they must manage the security certificates for the domain. Red Hat provides certificates for application routes if custom domains are not used as mentioned.

Ingress

Ingress policies can be changed by using NetworkPolicy objects, which leverage the ovs-networkpolicy plug-in. This allows for full control over ingress network policy at the pod level, including between pods on the same cluster and even in the same namespace. Additional load balancers can be purchased and configured for services requiring Non-HTTP/SNI traffic or non-standard ports.

Egress

As an OpenShift Dedicated cluster administrator, you can use the egress firewall policy to limit the external addresses that some or all pods can access from within the cluster. Pods can only communicate with internal hosts, and cannot initiate connections to the public Internet or pods can communicate with the Internet, but not to internal hosts. Public outbound traffic from the master and infrastructure nodes is allowed and is necessary to maintain cluster image security and cluster monitoring. See Using an Egress Firewall to Limit Access to External Resources for more information

Enabling HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) policy is a security enhancement, which ensures that only HTTPS traffic is allowed on the host. Any HTTP requests are upgraded to HTTPS by default. This is useful for ensuring secure interactions with websites for the user’s benefit. see Enabling HTTP Strict Transport Security for more information.