$ oc get clusterrolebinding.rbac -n test1234
Learn about assigning user and group access.
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.
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
Manage users and groups.
Manage roles and bindings.
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
$ oc get clusterrolebinding.rbac -n test1234
To view local roles for the
$ oc get rolebinding.rbac -n test1234
See Administering an OpenShift Dedicated Cluster for more information.
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:
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.
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
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.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
Serving Certificate Secrets for more information.
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.
See the Routes topic for an overview of routes, including route-specific annotations and IP whitelisting.
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 policies can be changed by using
NetworkPolicy objects, which leverage
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.
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
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.