An introduction to OpenShift 4
Continuing the story of Red Hat OpenShift on IBM Cloud
Red Hat® OpenShift® continues to evolve to springboard Cloud Native Development. As our history of Kubernetes, and OpenShift blogpost suggested last year, the recent V4 release of OpenShift V4 is the well considered contemporary enterprise platform, for building production ready apps on today, and for the decade ahead.
We’re excited that OpenShift 4.3 is now available on IBM Cloud.
In this blog post, I highlight some of the new features of OpenShift 4, and also introduce a new collection of developer resources here on the IBM Developer website, that explore those features, while digging into considerations for building secure, privacy conscious applications with container technology.
What’s new in OpenShift 4?
IBM Cloud is updating from OpenShift 3.11 to OpenShift 4.3. Now, OpenShift is even more packed with enterprise developer features, a few of which I’ll highlight below:
If you’re used to OpenShift 3.11, then you’ll immediately notice a visual refresh of the user interface. It is designed to be cleaner, and more organized – more focus, less noise. Red Hat even open sources their design process, which I find inspiring. You can read more about the design intentions of the dashboards, and even plug into the the ongoing design process for OpenShift.
Here’s a screen capture of the dashboard for our “Example Loyalty” app that we developed to explore some of the new features of OpenShift 4.
And here’s a screen capture of the cool new topology view that helps visualize the microservice architecture of a cloud native app, again showing the deployed components of the “Example Loyalty” app. You can read more about our intention with the app in the following diagram.
To learn more, see OpenShift 4.3 Dashboard refinements and the new Project dashboard.
The Operator Framework is an open source toolkit to manage Kubernetes native applications, called operators, in an effective, automated, and scalable way. OpenShift 4 was re-architected around operators. Where Kubernetes enabled developers to methodically containerize applications, Operators enable developers to automate the management of related components of an application (like databases or other stateful elements) in a consistent, repeatable, and scalable way.
In addition to operators as a part of the Kubernetes fabric in OpenShift 4, Red Hat introduced a marketplace for finding Operators that can accelerate development of an application. This new OperatorHub is also part of OpenShift. You can find out more in the Fun with OperatorHub tutorial.
OpenShift service mesh
Service meshes can instill a consistent development approach, and infuse inter-service communication with security and other features. I noticed that it is a choice approach for solving problems of scale and problems of order in big applications, and across large companies, described in KubeCon North America presentations last year.
OpenShift 4 adopted Istio, the emerging service mesh of choice for Kubernetes-based systems, building its own service mesh on that technology.
In addition, the latest version of Istio offers helpful security features, which is explored further in the Manage microservice traffic with the OpenShift service mesh code pattern.
OpenShift serverless computing
Serverless computing is increasing in developer appeal because it can offer reliability and scale of cloud computing. Code is typically written as small executable functions, an approach that sometimes requires a bit of lateral thinking to achieve a significant outcome.
Serverless development is enabled on OpenShift 4 through the adoption of the open source Knative project.
Cloud-native continuous integration (CI) and continuous delivery (CD) pipelines were introduced in OpenShift 4.1.
OpenShift pipelines build on the Tekton open source project, enabling teams to build cloud-native delivery pipelines that they can fully control. Your team can own the complete lifecycle of your microservices without having to rely on central teams to maintain and manage a CI server, plugins, and its configurations.
There is a new pipeline UI available, and in our introductory code pattern, we build in a rudimentary scanning step into a deployment pipeline, to demonstrate the potential for baking in security steps, with this emerging approach too.
Data security is an enormous concern these days, especially for enterprise businesses that handle tens or hundreds of thousands of client records.
OpenShift 4.3 delivers Federal Information Processing Standard (FIPS) compliant encryption and additional security enhancements. When OpenShift runs on Red Hat Enterprise Linux booted in FIPS mode, OpenShift calls into the Red Hat Enterprise Linux FIPS validated cryptographic libraries. The go language toolset that enables this functionality is available to all Red Hat customers.
The evolving world of secure and private applications
As noted earlier, OpenShift 4.3 introduces more security features for data sensitive apps and systems.
One of the themes that stood out to me at KubeCon Europe last year was the interest in GDPR.
GDPR has had a significant impact to data management since it was introduced in 2018. A couple of significant cases were filed against airlines and hotels for data sensitivity violations. This is especially in that these are typical “enterprise” software problem spaces.
While exploring OpenShift 4.3, I wanted to understand what it really takes to build secure, more private applications. What became clear was that there is no instant way, or even possible way of building a perfectly secure application – security is an ongoing challenge.
There are choices like building on a FIPS-compliant platform, which can start an app off with a solid security foundation. Then there are approaches, practices, and awareness that can establish a base of security, for cloud-native applications, and we can grow to understand a wider range of threats and ideas for thwarting them.
A helful discovery (again from a KubeCon talk that I attended) was about threat modeling using the STRIDE model. We have written our own code pattern that digs a little into what the STRIDE model is, and runs through a quick exercise considering options for tackling the different dimensions of security threats.
So we wanted to create a collection of OpenShift 4.3 content that introduces some of the main new features of the platform, while also thinking about how to build more secure applications. So we built a basic customer loyalty app.
Building a customer loyalty app example
The idea for building a loyalty app came from a real world request to build event check-ins into our IBM Developer mobile app. We’re still thinking about that idea. In our first version of our dev app, we were careful to avoid storing any user data at all, and so it was intriguing to question what it would take to store data in a GDPR friendly way.
We began scaffolding the app on OpenShift, to make ourselves question the steps we’d take to make it safe and secure. We turned this prototype into a web-based simulator for sharing our insight.
And we’ve open sourced our work in the form of a collection of code patterns, tutorials, and articles that show how we’ve used OpenShift 4 features to “build smart, build secure”.
Our collection includes:
A blog post highlighting some of the new features in OpenShift 4 that can truly help develop cloud native applications.
A JEE microprofile code pattern using operators to connect to a PostgreSQL database.
An tutorial that presents an overview on using operators in OpenShift 4.
A tutorial that steps through creating CI/CD pipelines that include custom steps on OpenShift 4.
An article that considers designing for privacy, and the STRIDE threat model.
In the coming weeks, we’ll build a little more content around this concept, including a code pattern that that digs into TLS/security in OpenShift service mesh and a code pattern that shows how to build with the emerging open standard for web components in the front end.
Our team is not a team of security experts. IBM, like many big companies, has its own advisors, and systems that are behind firewalls to protect data, so we would have an advanced starting point for a real application.
However, we think security is not just for experts to care about. Even for the experts, a cloud-native approach is a whole new world. We wanted to dive in, understand the arena more, raise awareness of the subject, and look at the options for starting from scratch, too. There’s a lot to think about.
Summary: prototype loyalty app architecture
Here’s the basic architecture of the loyalty app system we built on OpenShift 4. We use OpenShift pipelines and operators to deploy and set up a CI/CD for this system. You can fork the code to run the pipeline yourself, fork the constituent repo parts, or play with a live running version of the app.