Diese Präsentation beinhaltet Erfahrungen, Empfehlungen und Planungs-Gedanken, die man beachten sollte, wenn man multiple IBM Cloud Paks auf der Container Platform OpenShift installieren / deployen möchte. Es beschreibt die Grundlagen zu "common services", auch "foundational services" genannt, die als Basis-Services die Lauffähigkeit dieser Cloud Paks auf OpenShift erläutert und wie man Cloud Paks auch logisch trennen kann auf OpenShift worker nodes über taints und node selectors.
Call girls Service in Ajman 0505086370 Ajman call girls
IBM BP Session - Multiple CLoud Paks and Cloud Paks Foundational Services.pptx
1. Multiple Cloud Paks
auf OpenShift
Best Practices und
Empfehlungen
IBM Cloud Pak
Foundational Services
and
Automation Foundation
Georg Ember
IBM Deutschland
Brand Technical Specialist, IBM Automation
2. Table of Contents
A Platform for Multiple Cloud Paks
Architectural View of Cloud Paks on OpenShift
IBM Cloud Paks Foundational Services
Automation Foundation (Services)
Cloud Pak on OpenShift Dependencies
3. IBM Cloud Paks
Automate Predict Secure
• Customer Experience
• Business Ops
• Workforce Management
• App and Infrastructure Stability
• Platform Ops
• Optimize AI Ops
• Hybrid Cloud Integration
• Real-Time Interactions
• Transactional Integrity
• Site Deployment Automation
• 4G/5G Telco Cloud Platform
• NFV Lifecycle Management
• Data Modernization
• Data Ops
• AI Lifecycle Management
• Data Warehousing
• Trusted and Distributed AI
• Continuous Integrated Financial Planning
• Operational and IT Risk Management
• Customer Service Automation
• Textual / Document Analysis
• Advanced Threat Detection
• Data Security
• Incident Response
• Threat Hunting
• Risk Management
IBM Cloud Pak for Data IBM Cloud Pak for Security
Cloud Pak
for Business
Automation
Cloud Pak
for Watson
AIOps
Cloud Pak
for
Integration
Cloud Pak
for Network
Automation
IBM Cloud Pak Foundational Services and Automation Foundation Services
Red Hat OpenShift + RHEL
Enterprise-Grade Kubernetes Orchestration
IBM Cloud Public Cloud
AWS • Azure • GCP • Other
IBM Systems
Enterprise
Infrastructure
Edge 3
4. Cloud Pak Foundational Services
Red Hat OpenShift remains very much the core of this platform, with common Foundational Services
sitting atop of this platform to interoperate capabilities with the IBM Cloud Paks
Beneath the applications and Cloud Paks is the set of core, common, shared services — called the
Cloud Paks Foundational Services or (in brief) Foundational Services (aka “common services”)
4
8. Sizing and Deploying Foundational Services
8
https://www.ibm.com/docs/en/cloud-paks/1.0?topic=services-hardware-requirements-recommendations-foundational
Important: https://www.ibm.com/docs/en/cpfs?topic=co-installing-cloud-pak-foundational-services-in-
custom-namespace-version-37x-onwards
- You can install foundational services in a custom namespace only if you are installing them for the first
time in your cluster.
- You cannot migrate foundational services to another namespace if they are already installed in your
cluster.
- You can install foundational services in only one namespace in your cluster.
9. Cloud Pak for Data Example for Deploying Foundational Services
9
https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=tasks-installing-cloud-pak-foundational-services
10. Automation Foundation (Services)
IBM Automation foundation (IAF) provides a foundation for the IBM Cloud Paks for Automation.
Cloud Paks use the event framework that is built on
- Kafka cluster, Flink Cluster, Elasticsearch cluster, Apicurio instance
10
11. Automation Foundation Event Processing Framework
The following event framework (IBM Automation Foundation Event Processing) components are extra dependencies for Business
Automation Insights.
Apicurio Registry (iaf-system-apicurio)
Apicurio Registry is a datastore for sharing event schemas across event-driven architectures. You can share and manage your data types
and API descriptions at run time by using a REST interface.
Apache Kafka (ibm-events-operator)
A managed cluster that can be shared by IBM Cloud Paks. Each Cloud Pak is supplied with a set of credentials for Kafka that provides full
access to create, delete, read, and write resources.
Apache Flink (EventProcessor: iaf-flink image)
A framework and distributed processing engine for stateful computations over unbounded and bounded data streams.
Elasticsearch (ibm-elastic-stack-operator)
An Elasticsearch, Logstash, and Kibana (ELK) stack to collect and store all Docker-captured logs.
Zookeeper (iaf-system-zookeeper)
You can configure Flink clusters to work with high availability services like Zookeeper.
11
12. Automation (Foundation) Assets
IBM Automation assets
Users of the IBM Automation foundation are able to use the Automation assets to share assets across platform
capabilities. Storing assets, such as JSON schemas, within this repository allows them to be accessed directly within
the user interface of certain capabilities.
12
14. IBM Cloud Pak and Red Hat OpenShift version compatibility objective
https://www.ibm.com/support/pages/node/6457303
IBM Cloud Paks come with a Red Hat OpenShift limited (cloud pak only usage) license where both follow slightly
different lifecycle policies.
IBM objective is to continue stay compatible with Red Hat OpenShift releases.
IBM Cloud Pak Versions will focus on OCP EUS versions.
It will be necessary to update Red Hat OpenShift at least once during the Cloud Pak support lifecycle to remain on a
supported Red Hat OpenShift level.
All supported Cloud Pak continuous delivery versions will support the latest OpenShift EUS minor version (e.g. 4.6)
within 30 days of its release, for the duration of its support period.
To stay current with the updated RedHat OCP lifecycle policy (https://cloud.redhat.com/blog/time-is-on-your-side-a-
change-to-the-openshift-4-lifecycle), EUS versions are even minor releases beginning with 4.8.
14
15. Which common services will be installed by Cloud Paks ?
The Cloud Pak Operator installs the following services (if not already present) :
- Certificate management service (ibm-cert-manager-operator)
- Identity and Access Management Service (IAM Service) – if a specific userid to a GUI is needed.
- Administration hub (ibm-commonui-operator, e.g. ZEN)
- Automation Foundation (Event Processing)
Which common services will NOT be installed automatically by a Cloud Pak
(but you can install individually) :
- License Service
- Logging, Monitoring
- Metering, Auditing
- Robotic Process Automation (RPA)
15
16. Licensing Service just runs ONCE in an OCP cluster !
https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.4?topic=service-verifying-completeness-license-usage-data#validation
Note: Only one instance of License Service is deployed per cluster regardless of the number of IBM Cloud Pak
solutions and containerized products that you have installed on this cluster.
16
18. IBM Cloud Pak Installation Dependencies
https://www.ibm.com/docs/en/cloud-paks/1.0?topic=environment-preparing
After you've installed Red Hat OpenShift Container Platform, there are a set of tasks you can perform before installing
your IBM Cloud® Paks.
18
19. Placing Cloud Pak pods on OpenShift worker nodes using Taints
https://docs.openshift.com/container-platform/4.8/nodes/scheduling/nodes-scheduler-taints-tolerations.html
Taints and tolerations allow the node to control which pods should (or should not) be scheduled on them.
You apply taints to a node through the Node specification (NodeSpec) and apply tolerations to a pod through the Pod
specification (PodSpec).
When you apply a taint to a node, the scheduler cannot place a pod on that node unless the pod can tolerate the taint.
You can put multiple taints on the same node and multiple tolerations on the same pod. OpenShift Container
Platform processes multiple taints and tolerations
19
20. Node Selectors for Cloud Paks
https://docs.openshift.com/container-platform/4.8/nodes/scheduling/nodes-scheduler-node-selectors.html
A node selector specifies a map of key/value pairs that are defined using custom labels on nodes and selectors specified
in pods.
For the pod to be eligible to run on a node, the pod must have the same key/value node selector as the label on the
node.
You can use a node selector to place specific pods on specific nodes, cluster-wide node selectors to place new pods on
specific nodes anywhere in the cluster, and project node selectors to place new pods in a project on specific nodes.
You can use node selectors in a project together with labels / taints on nodes to constrain all pods created in that
project to the labelled nodes.
When you create a pod in this project, OpenShift Container Platform adds the node selectors to the pods in the project
and schedules the pods on a node with matching labels in the project.
20
21. Catalog Source and Entitlement Key
https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.4?topic=installing-adding-catalog-sources-online-
openshift-cluster
A catalog source (e.g. ibm-operator-catalog) should be specified for each Cloud Pak, either cluster-wide or per
namespace. It depends what is good for your org and installation type (online or air-gapped).
The entitlement key and pull-secret sometimes needs to be updated, if new Cloud Pak releases or image versions will
be pulled. This is due to access control of your purchased software products in PA.
21
22. Multiple Cloud Pak
Considerations and Planning
Important points to be planned ahead :
Which Cloud Paks together ?
Common Services or Closed Services ?
Storage Access Modes (default storage class)
OpenShift Cluster Version compatibility
Licensing and Node Limits
Networking Zones and Node placement
Inter-Cluster HA or Intra-Cluster HA ?
24. Foundational Services — 5 Key Pillars
The foundational Foundational Services (accessible by each of the IBM Cloud Paks) represent aggregations
of microservices, technologies, and capabilities.
Foundational Services can be organized into 5 distinct pillars:
Application Services, Security Services, Operational Services, User Experience, and Data Services
• Each pillar of services support a common, consistent operational experience, user experience, and integration experience
• Not every Platform Service will be transparent to end-users or customers, but each service will directly (or indirectly) benefit
those audiences
• These services are not something that can be purchased from a catalog — they are embedded as part of the IBM Cloud
Paks experience on top of OpenShift (and eventually the Cloud Paks Platform)
Application
Services
Data & Event
Services
Operational
Services
Security
Services
User Experience
Services
IBM Cloud Paks Foundational Services
Certification and Governance for Enterprise Standards
24
25. Operational Services — Logging & Monitoring
WHO
• DevOps Managers, Site Reliability Engineers (SREs), Developers
WHAT
• Built on top of an Elasticsearch, Fluentd, and Kibana stack, it provides pre-configured and
self-updated logging services for both the Platform cluster and applications running atop of it
WHY
• DevOps teams and Site Reliability Engineers (SREs) can easily view real-time resource utilization of
Cloud Paks services and applications, allowing clients to isolate and resolve application issues quickly
• Logging information is integrated with role based access control (RBAC) so that teams can only see
what they are authorized to see
25
26. Security Services — Certificate Management
WHO
• IT Security and Ops, System Administrators, Regulators
WHAT
• The certificate manager can automatically refresh leaf certificates created from a CA issuer,
using KeyProtect from IBM Cloud
WHY
• Administrator can easily configure my preferred certificate authority and know that services will
utilize the right standards for secure interactions
• Certificate management gives clients the ability to easily secure service interactions without concern
for the certificate authorities that customers have established
26
27. Security Services — Identity and Access Management
WHO
• IT Security and Ops, System Administrators, Regulators
WHAT
• Customers can use common login, SSO, manage RBAC to resources across their IBM Cloud Paks
investments, and integrate with their identity provider of choice
WHY
• Customers can log in once and navigate between various Cloud Paks, common services, and OpenShift
Container Platform without ever being presented with another authentication-related screen for the
duration of their active session
27
28. UX Services — Application Lifecycle UI
WHO
• Operations Managers, Cluster Managers, Developers
WHAT
• Provides a UI component library for instance creation, editing, and upgrade
• Adds basic CRUD (create-read-update-delete) operations on custom resource APIs
WHY
• Customers of multiple Cloud Paks will be able to readily and easily move from one to the other
• Creating and managing software instances will be more consistent, regardless of what service
a customer is working with
28
29. Security Services — Audit Logging (Compliance)
WHO
• IT Security and Ops, System Administrators, Regulators
WHAT
• A common audit logging service and framework simplifies and standardizes the delivery of software
capabilities that can be configured to log security events and comply with common policies
WHY
• Products running on the platform can easily be configured to log security events, for compliance with
common internal or external security policies
• Accelerated delivery of products that comply with common security postures, through adoption of a
common service and format, instead of developing their own
29
30. UX Services — Bedrock Administration Hub
WHO
• Cluster Administrators, Operations Managers, Developers
WHAT
• Provides a central point for configuration, information, and interaction with IBM Cloud Paks and
other Foundational Services installed in an OpenShift cluster
WHY
• Provides a consistent experience for IBM customers looking to conduct administration across their
Cloud Paks investments
• They need to understand at a glance which Cloud Paks are running, how resources are being consumed
across the cluster, the ability to add users for Cloud Paks, and trigger serviceability connections
30
Notas del editor
In this presentation you will learn how common services, containers, and an orchestration platform come together to enable modernized application services that is ready for the hybrid multicloud world. This presentation explores how IBM Cloud Paks Foundational Services are critical to a customer’s success in this endeavor.
Table of contents for this presentation.
Let's start with examining the 3 core aggregations— "Security," "Data," and "Automation" (and their respective Cloud Paks) —at the top, and then progress further down the stack to the underlying common Foundational Services, to the OpenShift Container Platform for Kubernetes orchestration, to the infrastructure at the base.
This chart depicts the catalog of Cloud Paks as they exist in April 2021 and going into 2022. The Cloud Paks are aggregated into three pillars of Security, Data, and Automation, with details below those pillars on the types of use cases and personas that these collections of Cloud Paks are intended to support.
Those of you familiar with the history of Cloud Paks will recognize that IBM already had a Cloud Pak for Data and a Cloud Pak for Security in the past, yet today and going forward "Security" and "Data" are also the names of the pillars (to which these Cloud Paks belong). It's important to frame conversations of these three pillars with customers as "capabilities" and "use case" value, rather than getting into the underlying Cloud Paks too soon in the discussion. Remember: IBM is aiming to further and further remove the boundaries between the individual Cloud Paks (moving from verticals to horizontals). Your focus should be on what are use cases and personas you're targeting (as a seller), what are the capabilities your customers need to address those challenges, and what Cloud Paks we can recommend as a solution. Keep in mind as well that the integrated nature of Cloud Paks (today, and increasingly so going forward) means that customers can consume Cloud Paks capabilities in a modular and ad-hoc fashion, integrating them seamlessly in support of applications running atop OpenShift and Cloud Paks stacks.
Cloud Paks: yes they are containerized, yes they run on OpenShift, yes they are getting certified. But they are also packaged in what could be described as a "coarse grain view" of IBM software: with each Cloud Pak are multiple capabilities that support specific use cases and personas, aggregated into a single offering, pre-integrated so it can be installed as one thing. Customers can pick and choose the capabilities out of that to support their own applications and services. This is essentially what IBM calls a Cloud Pak: an aggregation of capabilities, in containerized form, running on Red Hat OpenShift as the hybrid multicloud platform. This layering has been around for a while and hasn't gone away.
In 2019-2020, when IBM first began work on IBM Cloud Paks in earnest, the general philosophy of the architecture was to have Cloud Paks running atop of OpenShift, with a layer of "Bedrock" core services layered between the two. Compare that to today's architecture and you'll find that this more or less remains the case. OpenShift remains very much the core of this platform, common "Foundational Services" are still sitting atop of this platform to interoperate capabilities with the Cloud Paks, and the Cloud Paks (of which there were 6 flavors at the time in 2019-2020) remain at the uppermost strata of the layers.
There is a fundamental difference, however, with respect to the Cloud Paks and core Foundational Services, and the relationship these components have with one another. The challenge IBM encountered (internally in terms of management and externally with respect to customer adoption) was that the earlier generation of Cloud Paks were relatively isolated and siloed from one another. The architecture was too "vertical" and created too much friction when trying to integrate capabilities across the various Cloud Paks solutions.
The future-facing direction and philosophy of Cloud Paks is to rearchitect Cloud Paks from a series of "verticals" into "horizontals," in order to break down the silos between the various services and truly embrace the "plug and play" (modular) vision of Cloud Paks. The first step was started in 2020-2021 and continues into 2021-2022 (and beyond.) The new wave of Cloud Paks represents that evolution. Instead of having six discrete Cloud Paks, IBM has three functional "pillars" around Security, Data, and Automation.
Security and Data existed as distinct Cloud Paks before, and the newly-created "Automation" pillar in fact contains multiple Cloud Paks tailored for specific use cases or needs. The result is that Cloud Paks are now organized based on aggregations of capabilities (capabilities around Data, around Security, around Automation), in support of specific personas and customers. While these labels may change slightly over time— there might be some repackaging, one box may move from one aggregation into another, or may move into the Foundational Services (underlying all of this) in order to service all of the Cloud Paks atop —but overall this is the structure IBM is building towards and it's a fair assumption that these three pillars will be where future capabilities live.
IBM’s strategic long term goal is the creation of one IBM Cloud Paks Platform (CPP). All of IBM’s software capabilities will be built upon and running on a common base: with a common operational model, a common user experience across everything, a common set of basic technologies and other capabilities available in that ecosystem, and then on top of that common base a set of specific capabilities (Cloud Paks) in support of precise use cases or personas that a customer can select from in a very granular way. To bring things back to the "verticals" and "horizontals" mentioned earlier, IBM is ultimately moving from multiple vertically-aligned Cloud Paks silos to a single horizontally-integrated Cloud Paks Platform. Everything IBM is doing architecturally today is in support of that end-goal.
Beneath the applications and Cloud Paks is the set of core, common, shared services. What we call "Cloud Paks Foundational Services" or simply "Foundational Services."
IBM and product naming are strange bedfellows. Particularly so in the case of services that IBM doesn’t "sell" (per se), such as the Foundational Services depicted here, which aren't sold as a standalone catalog product but nevertheless are of critical value to customers. As such, you may hear Foundational Services described by a slew of different names, depending on where you look: core services, foundations, and so on. Understand that all of these terms are referring to the same thing— the layer between the Cloud Paks containerized software above and the OpenShift container orchestration platform below —what we call "Foundational Services."
The five pillars you see depicted on this chart are similar to the 3 groupings (Security, Data, Automation) shown earlier on the Cloud Paks architecture slide. They represent aggregations of microservices, technologies, and capabilities of Foundational Services into 5 distinct pillars: Application Services, Security Services, Operational Services, User Experience, and Data Services. We will go into each of these in much further detail later on in this presentation. For now, understand that the pillars on this chart are in support of a common, consistent operational experience, user experience, and integration experience. Not all of these items are going to be something a customer needs to concern themselves well. In fact, with Foundational Services, a significant benefit of having this shared common layer across all of the Cloud Paks is that customers don't need to worry about these components — but they give IBM huge gains in efficiency and consistency with regards to maintaining and developing the OpenShift and Cloud Paks Platform.
One example of "things that keep us up at night" as systems administrators and purveyors of "as a Service" offerings is the use of data services. Obviously IBM has many capabilities across its portfolio that make use of data. We at IBM often need to ask ourselves: can everyone bring their own database? How many different flavors of SQL do we need and can support on this platform? Wouldn't it make more sense if we were to go and consolidate on a known and well-defined set of SQL and NoSQL data services, and then have IBM customers prioritize use of those databases, instead of rolling their own each time? That provides IBM with significant efficiency gains (in the sense that IBM doesn’t need to reinvent the wheel and duplicate efforts across the board). It also makes it easier for us to run all of these things in concert, or run them on the same cluster, and we avoid things such as versioning or implementation conflicts between different versions of different things. All of this translates to a better quality of life and experience for our customers, who no longer need to ask questions about "how is it implemented?" but rather focus on "what can this software do for me?"
Bedrock Administration Hub (“Admin Hub”)
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/UXServices/Bedrock-Administration-Hub.html
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/AdopterGuides/AdminHubAdoption.html
WHO
Cluster Administrators
Operations Managers
Developers
WHAT
The Admin Hub provides a central point for configuration, information, and interaction with IBM Cloud Paks and other Foundational Services installed in an OpenShift cluster. The service is typically used by the Cluster Administrator to:
Ensure that Cloud Paks and their required Foundational Services are installed and running correctly
Administer identity management through the Identity and Access Manager (IAM)
Manage license compliance for IBM containerized offerings
Launch into the OpenShift console in the context of IBM offerings for more detailed analysis
Gather cluster information and specific IBM offering information for use in problem determination or reporting issues to support
WHY
The Admin Hub provides a consistent experience for IBM customers looking to conduct administration across their Cloud Paks investments. Administrators need to understand at a glance: which Cloud Paks are running; how resources are being consumed across the cluster; the ability to add users, teams, and roles for actively-running Cloud Paks; and the ability to trigger serviceability connections.
Table of contents for this presentation.
Licensing
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/OperationalServices/Licensing.html
WHO
System Administrators
Lines of Business
Operations Managers
WHAT
The License Service provides license consumption reporting and audit readiness for IBM containerized software. It is required for license tracking of IBM Cloud Pak solutions and IBM Certified Containers, and covers the requirements that are defined by IBM’s worldwide (WW) pricing guidelines (as well as outlining of customer obligations as defined in the Container Licensing rules). The License Service is also useful to any customer that wants to view and understand their license consumption of IBM Certified Container Software or IBM Cloud Pak solutions running on a Red Hat OpenShift cluster. It also supports non-OpenShift environments like IBM Cloud public Kubernetes clusters. It also provides optional support for sending the collected license usage data to Red Hat Marketplace via optional configuration. Starting with the IBM Cloud Paks Foundational Services v3.5 release, the License Service provides another optional component— License Service Reporter —with a Web UI that displays information on multi-cluster license usage, simplifying how customers consolidate data from multiple clusters and traditional IBM License Metric Tool (ILMT) deployments.
WHY
A license consumption service is immensely useful for any customer that wants the ability to check the VPC license consumption of an IBM Certified Container or IBM Cloud Paks running on a Red Hat OpenShift cluster. Customers can determine their daily license utilization, or check if they are in compliance with respect to the purchased licenses quantities, for all IBM Cloud Paks or Certified containers in any cluster. In turn, customers will be able to understand what they have installed and how heavily they are utilizing those licensed offerings. Enterprise clients in particular need to be always ready for software audits. They require a certified backend license counting tool that is continuously capturing VPC license consumption of IBM software —and ready at any time to generate a digitally signed audit snapshot, required by IBM Compliance during any audit activities.
Table of contents for this presentation.
How does IBM prevent OpenShift and Cloud Paks from becoming a large, monolithic mess that we can't reasonably install on a customer system? Particularly if a customer wants to start small? (Which, obviously, many customers do want to start small.) A lesson learned the hard way in the past is that no vendor can go to a customer on Day 1 and say: "Here's a production-ready environment. By the way, you'll need to set up X number of servers and workers nodes before you can even run 'Hello, World!' Good luck."
Instead, certification and standards spell out a clear set of principles that directly guide how IBM wants to build the common Foundational Services and how to define a consumption model for them. One of the most important of these principles is that everything in Bedrock needs to be OPTIONAL. After all, IBM wants to support the start-small initiatives of its customers, as much as the expansive full-stack requirements of its enterprise clients.
IBM wants to get away from going to customers and asking them to install OpenShift, then Foundational Services, and then Cloud Paks — when really all that the customer wanted was access to the Cloud Paks in the first place. This approach reverses the conversation so that on Day 1 an IBM seller can have the conversation with a customer along the lines of: "What are the capabilities you need, which Cloud Paks meet that requirement, and how can common Foundational Services pull those capabilities together and deploy them under the covers, where and when they are needed?"
In that respect, it's useful to avoid thinking about Foundational Services as yet another "first class citizen" layer within the Cloud Paks stack. After all, Foundational Services aren't a catalog item that customers will be making a purchase order for. Instead, Foundational Services are deliberately designed be a SECOND CLASS CITIZEN because everything done in Foundational Services is in direct support of the functionality of the Cloud Paks themselves. Cloud Paks are IBM offerings — they are what IBM goes to market with and what customers order off the catalog. Foundational Services are NOT an offering and will NOT be a product that we sell (directly), but it's nevertheless a tremendous means to an end and value-add.
Logging & Monitoring
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/OperationalServices/Logging.html
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/OperationalServices/Monitoring-Redhat-Application-Monitoring-Service.html
WHO
DevOps Managers
Site Reliability Engineers (SREs)
Developers
WHAT
Built on top of an Elasticsearch, Fluentd, and Kibana stack, it provides pre-configured and self-updated logging services for both the platform cluster and applications running atop of it. Clients are able to easily view and understand Cloud Paks observability metrics, integrating these logging tools with their own services. The Foundational Service's monitoring is built on top of Prometheus and uses pre-installed Grafana to query and visualize cluster metrics. Prometheus is an open source project designed for event monitoring and alerting, particularly for time series data where the capture of real-time metrics is essential. Grafana likewise focuses on time series data and specializes in providing interactive visualizations (charts, graphs, and alerts) for such data points.
WHY
DevOps teams and Site Reliability Engineers (SREs) can easily view real-time resource utilization of Cloud Paks services and applications, allowing customers to isolate and resolve application issues quickly. Application logs are consolidated in a common location, with search and aggregation available on those records to help administrators isolate and resolve problems more efficiently. Logging information is integrated with role based access control (RBAC) so that teams can only see what they are authorized to see.
Certificate Management
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/SecurityServices/Certificate-Management-data-security.html
WHO
IT Security and Ops
System Administrators
Regulators
WHAT
The certificate manager can automatically refresh leaf certificates created from a certificate authority (CA) issuer, using KeyProtect from IBM Cloud.
WHY
CA issuers, within the scope of cryptography, are able to issue digital certificates that give proof of some entity’s ownership of a public key (certifying that the public key is valid and therefore trusted for use with your personal ‘private’ key). By providing a Certificate Management layer within IBM Cloud Paks Foundational Services, administrators can easily configure their environment to work with their preferred CA issuers, and know that Cloud Paks services (or applications built atop of them) will utilize the right standards— every time —for secure interactions. Customers only need to integrate the Foundational Service with their existing security standards, infrastructure, and applications.
Identity and Access Management (IAM)
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/SecurityServices/Identity-and-Access-Management.html
WHO
IT Security and Ops
System Administrators
Regulators
WHAT
Customers can use common login, single sign-on (SSO), manage role-based access controls (RBAC) to resources across their Cloud Paks investments, and integrate with their identity provider of choice. SSO allows users to log in and access all capabilities of the Platform, without needing to repeatedly log in again from the same system (or device). RBAC in particular will help customers tailor the users’ platform capabilities (what they can and cannot see within the platform) according to that user’s roles and level of access within your organization. The Access Management component provides a set of prebuilt roles and permissions as well.
There are two key dimensions to what the Identity and Access Management service provides IBM Cloud Paks: it helps define roles and permissions which govern access to the capabilities provided by the platform; secondly, it provides access controls to Kubernetes orchestration resources via "Kubernetes Access Management" for customers that need access to Kubernetes namespaces and control over which users can access those namespaces. This component will update the Kubernetes namespace using the Kubernetes RBAC mechanism.
Consumers of the IAM Foundational Service will integrate using Open ID Connect (OIDC) or OAuth protocols. The IAM component will allow integrations that leverage both API and Web Browser flows. OIDC and OAuth flow are the preferred standards, without eliminating the possibility of including non-standard flows to support backward compatibility or to accommodate user scenarios not contemplated by the specification (i.e. API Key-based grant types). Applications running atop of the IBM Cloud Paks will register with the IAM component to act as an OIDC / OAuth client / relying party. The IAM component will be the issuer of security tokens by acting as the OIDC / OAuth authorization server.
WHY
Customers can log in once and navigate between various Cloud Paks, common services, and OpenShift Container Platform without needing to be presented with additional authentication-related screen for the duration of their active session. They can easily integrate existing enterprise directories into authentication and authorization for IBM Cloud Paks. For administrators overseeing one or more Cloud Paks capabilities, it is vital to be able to easily locate users and manage their access to resources and services. An administrator can easily view and filter IAM content to show items relevant to a particular Cloud Pak or namespace, eliminating potentially tedious and confusing manual browsing of environments where multiple Cloud Paks are running.
Application Lifecycle UI
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/UXServices/Application-Lifecycle.html
WHO
Operations Managers
Cluster Managers
Developers
WHAT
Provides a UI (user interface) component library for instance creation, editing, and upgrades. IBM Cloud Paks make use of operators to managing custom resources and deliver capabilities to end-users. Naturally, those IBM Cloud Paks need to be able to manage the lifecycle of those custom resources over time. The Application Lifecycle UI provides a clean, simple, configurable sets of components for each of these lifecycle operations. It also provides an express router which enables basic CRUD (Create, Read, Update, Delete) operations on custom resource APIs. For example:
Cloud Pak for Integration users can create instances of integration capabilities from within the platform navigator UI
App Connect users can deploy instances of integration servers from within the App Connect Dashboard
Users of a common service catalog will need to create instances of those services via the UI
WHY
Customers of multiple IBM Cloud Paks will be able to readily create and manage software instances, custom resources, and resource lifecycles in a more consistent fashion, regardless of what service a customer is working with.
Audit Logging (Compliance)
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/SecurityServices/Audit-Logging.html
WHO
IT Security and Ops
System Administrators
Regulators
WHAT
A common audit logging service and framework that simplifies and standardizes the delivery of software capabilities, which can be configured to log security events and comply with common security policies. The service uses a variety of technologies to carry out audit logging and compliance checks, including:
CADF (Cloud Auditing Data Federation) - Audit logging format standards
Sysflow - Tool suite for monitoring system behavior for scalable security, compliance, and performance analytics
Fluentd - Open Source data collector for audit logs
WHY
Products running on the platform can be easily configured to log security events in order to maintain compliance with common internal or external security policies. The service accelerates the delivery of products that comply with common security postures, through adoption of a common service and format, instead of requiring customers to develop their own (from scratch) each time. For example, a client might request to configure their software capabilities to log security events in support of internal or external audits, governance, or compliance mandates. By using IBM Cloud Paks and the Foundational Services layer, those clients can automatically collect identity and access (create, read, update, and delete) information to comply with industry compliance standards (e.g. PCI, FISMA, or HIPPA ). When using Cloud Paks capabilities in their development pipelines, customers gain access to the tools needed to deliver compliant solutions. When security problems arise, they can quickly track down identity and access patterns that may have been responsible for the incident.
PCI: Payment Card Industry data security standard that ensures all companies accept, process, store, and transmit credit card information in a secure environment.
FISMA: Federal Information Security Management Act, established in 2002 by the US federal government, mandates federal agencies to develop, document, and implement information security strategies across said agencies and their partners or contractors.
HIPPA: Health Insurance Portability and Accountability Act provides national standards, guidance, and protections for personal health information within the United States of America.
Bedrock Administration Hub (“Admin Hub”)
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/UXServices/Bedrock-Administration-Hub.html
https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/AdopterGuides/AdminHubAdoption.html
WHO
Cluster Administrators
Operations Managers
Developers
WHAT
The Admin Hub provides a central point for configuration, information, and interaction with IBM Cloud Paks and other Foundational Services installed in an OpenShift cluster. The service is typically used by the Cluster Administrator to:
Ensure that Cloud Paks and their required Foundational Services are installed and running correctly
Administer identity management through the Identity and Access Manager (IAM)
Manage license compliance for IBM containerized offerings
Launch into the OpenShift console in the context of IBM offerings for more detailed analysis
Gather cluster information and specific IBM offering information for use in problem determination or reporting issues to support
WHY
The Admin Hub provides a consistent experience for IBM customers looking to conduct administration across their Cloud Paks investments. Administrators need to understand at a glance: which Cloud Paks are running; how resources are being consumed across the cluster; the ability to add users, teams, and roles for actively-running Cloud Paks; and the ability to trigger serviceability connections.