As of OpenShift Dedicated on 3.7, a reserved project called dedicated-admin will be created and maintained on each cluster. Any service account created within this project will have dedicated-admin permissions by default. Only dedicated-admin users will be able to manage service accounts within this project.

As of OpenShift Dedicated on 3.7, dedicated-admin users will be able to list and delete oauthclientauthorizations.

As of OpenShift Dedicated on 3.7, dedicated-admin users will be able to access scheduler statistics for each node by using the oc describe node command.

Many core features Google announced in June for Kubernetes 1.7 were the result of OpenShift engineering. Red Hat continues to influence the product in the areas of storage, networking, resource management, authentication and authorization, multi-tenancy, security, service deployments, templating, and controller functionality.

While OpenShift Dedicated is a secured by default implementation of Kubernetes, there is now documentation on what security protocols and ciphers are used.

OpenShift Dedicated leverages Transport Layer Security (TLS) cipher suites, JSON Web Algorithms (JWA) crypto algorithms, and offers external libraries such as The Generic Security Service Application Program Interface (GSSAPI) and libgpgme.

Private and public key configurations and Crypto levels are now documented for OpenShift Dedicated.

Pods can no longer try to gain information from secrets, configuration maps, PV, PVC, or API objects from other nodes.

Node authorizer governs what APIs a kubelet can perform. Spanning read-, write-, and auth-related operations. In order for the admission controller to know the identity of the node to enforce the rules, nodes are provisioned with credentials that identify them with the user name system:node:<nodename> and group system:nodes.

Network Policy is now fully supported in OpenShift Dedicated using 3.7.

Network Policy is an optional plug-in specification of how selections of pods are allowed to communicate with each other and other network endpoints. It provides fine-grained network namespace isolation using labels and port specifications.

After installing the Network Policy plug-in, an annotation that flips the namespace from allow all traffic to deny all traffic must first be set on the namespace. At that point, NetworkPolicies can be created that define what traffic to allow. The annotation is as follows:

$ oc annotate namespace ${ns} 'net.beta.kubernetes.io/network-policy={"ingress":{"isolation":"DefaultDeny"}}'

The allow-to-red policy specifies "all red pods in namespace project-a allow traffic from any pods in any namespace." This does not apply to the red pod in namespace project-b because podSelector only applies to the namespace in which it was applied.

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: allow-to-red
spec:
  podSelector:
    matchLabels:
      type: red
  ingress:
  - {}

See Managing Networking for more information.

HTTP Strict Transport Security (HSTS) ensures all communication between the server and client is encrypted and that all sent and received responses are delivered to and received from the authenticated server.

An HSTS policy is provided to the client via an HTTPS header (HSTS headers over HTTP are ignored) using an haproxy.router.openshift.io/hsts_header annotation to the route. When the Strict-Transport-Security response in the header is received by a client, it observes the policy until it is updated by another response from the host, or it times-out (max-age=0).

Example using reencrypt route:

Clients can now easily invoke a server API instead of relying on client logic.

See Template Instantiation for more information.

In OpenShift Dedicated on 3.7, Chaining Builds is a better approach for producing runtime-only application images, and fully replaces the Extended Builds feature.

Benefits of Chaining Builds include:

OpenShift Dedicated on 3.7 provides a better initial user experience with the Service Catalog. This includes:

The new user interface is designed to really streamline the getting started process, in addition to incorporating the new Service Catalog items. These Service Catalog items are not yet available in OpenShift Dedicated.

OpenShift Dedicated on 3.7 provides a simple way to quickly get what you want The new Search Catalog user interface is designed to make it much easier to find items in a number of ways, making it even faster to find the items you are wanting to deploy.

Provision a service from the catalog. Select the desired service and follow prompts for the desired project and configuration details.

Once a service is deployed, get coordinates to connect the application to it.

The broker returns a secret, which is stored in the project for use. You are guided through a process to update the deployment to inject a secret.

Since templates are now served through a broker, there is now a way for you to deploy templates from other projects.

Upload the template, then select the template from a project.

Key notifications are now under a single UI element, the notification drawer.

The bell icon is decorated when new notifications exist. You can mark all read, clear all, view all, or dismiss individual ones. Key notifications are represented with the level of information, warning, or error.

Quota notifications are now put in the notification drawer and are less intrusive.

There are now separate notifications for each quota type instead of one generic warning. When at quota and not over quota, this is displayed as an informative message. Usage and maximum is displayed in the message. You can mark Don’t Show Me Again per quota type. Administrators can create custom messages to the quota warning.

Anything with a pod template now supports the EnvFrom construct that lets you break down an entire configuration map or secret into environment variables without explicitly setting env name to key mappings.