Release notes

Red Hat Advanced Cluster Management for Kubernetes 2.2

Red Hat Advanced Cluster Management for Kubernetes Release notes

Red Hat Advanced Cluster Management for Kubernetes Team

Abstract

Red Hat Advanced Cluster Management for Kubernetes release notes, what's new and known issues

Chapter 1. Red Hat Advanced Cluster Management for Kubernetes Release notes

1.1. What’s new in Red Hat Advanced Cluster Management for Kubernetes

Red Hat Advanced Cluster Management for Kubernetes provides visibility of your entire Kubernetes domain with built-in governance, cluster lifecycle management, and application lifecycle management, along with observability. With this release, you can move towards managing clusters in more environments, GitOps integration for applications, and more. Learn more about what is new this release:

1.1.1. Installation

You can now install your hub cluster in the Red Hat OpenShift Dedicated environment. For more information, see Installing while connected online.

1.1.2. Web console

You can now define the storage settings for search persistence. Persistence is enabled by default with the searchCustomization custom resource. For more information, see Search in the console.

1.1.2.1. Observing environments

  • Certificates for observability are now automatically renewed before expiration is met. For more information, see Observability certificates.
  • The following additional metrics are available with Red Hat Advanced Cluster Management and are included with telemetry, but are not displayed on the Red Hat Advanced Cluster Management Observe environments overview dashboard:

    • visual_web_terminal_sessions_total
    • acm_managed_cluster_info
  • You can now add custom metrics to the observability service, which are collected from managed clusters. For more information, see Adding custom metrics.
  • Observability automatically restricts configuration changes for observability resources (observability-xxx) in managed clusters to confirm that clusters are in a desired state. This is also applied in the hub cluster. Undesirable updates are reverted. See Customizing observability to learn how to customize the observability service.
  • You can now design Grafana dashboards for your cluster. For more details, see Designing your Grafana dashboard.
  • OpenShift Container Storage is now a supported storage solution for the observability service. For more information, see Enable observability service.

To learn more about observability, see Observing environments introduction.

1.1.3. Cluster management

1.1.4. Application management

You can connect to a private repository using self-signed certificates, which is an improvement in Git connection ability. See Configuring application channel and subscription for a secure Git connection for more information.

Argo CD is integrated now so that you can manually sync any type of supported managed cluster. Enable the Argo CD cluster collection so that you can deploy applications from Argo CD to your managed clusters. See Configuring managed clusters for Argo CD to learn how to enable Argo CD.

For all the application management changes and documentation, see Managing applications.

1.1.5. Security and compliance

  • You can now install gatekeeper with the Red Hat Advanced Cluster Management gatekeeper operator policy. See Installing gatekeeper using a gatekeeper operator policy for more information.
  • You can now install the Red Hat OpenShift Container Platform compliance operator with the compliance operator policy. See Compliance operator policy for more details.
  • You can now create and apply an Essential 8 (E8) scan policy to scan master and worker nodes for compliance with the E8 profiles. For more details, see E8 scan policy.
  • You can now rotate internal managed certificates. For more information, see Certificates.

See Governance and risk to learn more about the dashboard and the policy framework.

1.2. Errata updates

By default, errata updates are automatically applied when released. See Upgrading by using the operator for more information.

Important: For reference, Errata links and GitHub numbers might be added to the content and used internally. Links that require access might not be available for the user.

1.2.1. Errata 2.2.2

View a summarized list of Red Hat Advanced Cluster Management for Kubernetes Errata 2.2.2 updates:

  • This errata addresses multiple security issues and container image updates.
  • Resolved an issue with an existing policy in the create policy form displaying a blank page. (Bugzilla 1940588)
  • Added the Gatekeeper operator policy, which is now available in the Create policy specification drop-down menu. (GitHub 10447)
  • Fixed an Application topology deployment status issue. The Helm resources chart now displays the resource deployment status when the custom alias doesn’t match the package name. (GitHub 10401)
  • Fixed an issue with ObservabilityAddon in terminating status. (GitHub 10012)
  • Added the ability to create Azure clusters for all possible regions. (GitHub 9700)
  • Fixed an issue with custom certificate authority on hub cluster. Submariner agent can now connect. (GitHub 9894)
  • Fixed an issue with packageOverrides that were incorrectly specified in subscription CR. Errors occurred on a pod on the hub cluster, or the klusterlet-addon-appmgr pod on the managed cluster. The log now ignores the override. (GitHub 9700)
  • Updated the Visual Web Terminal CLI to support OpenShift Container Platform version 4.7. (GitHub 9640)
  • Updated import cluster commands with double quotes to handle unescaped characters. Be sure to use base64 with the -d option. (GitHub 10748)
  • Fixed an issue with the cluster YAML editor. (Bugzilla 1941778)
  • Added support for NodeJS version 14 from version 12 to limit vulnerabilities in the base image. (GitHub 9540)
  • Updated the ServiceExport API version in the base image. (Bugzilla 1936528)
  • Fixed a bare metal asset issue where assets that were originally referenced in clusterdeployment could not be reused for another clusterdeployment. (GitHub 9272)
  • Fixed a bare metal issue that caused updates too frequently. (GitHub 9463)
  • Changed the Application management default reconcile rate to 15 minutes. The reconcile rate is also now configurable. (GitHub 10644)
  • Fixed resource issues with the default alert manager by removing the KubeAPIServerLatency rule. (GitHub 10693)
  • Updated role-based access control. Added authorization for the Viewer role to create and delete the ManagedClusterView resource, and added authorization for cluster-manager-admin users to get and view logs for pods. (GitHub 11243, 11242)

1.2.2. Errata 2.2.1

View a summarized list of Red Hat Advanced Cluster Management for Kubernetes Errata 2.2.1 updates:

This errata release delivers a new set of container images.

1.3. Known issues

Review the known issues for Red Hat Advanced Cluster Management for Kubernetes. The following list contains known issues for this release, or known issues that continued from the previous release. For your Red Hat OpenShift Container Platform cluster, see OpenShift Container Platform known issues.

1.3.1. Installation known issues

1.3.1.1. OpenShift Container Platform cluster upgrade failed status

When an OpenShift Container Platform cluster is in the upgrade stage, the cluster pods are restarted and the cluster might remain in upgrade failed status for a variation of 1-5 minutes. This behavior is expected and resolves after a few minutes.

1.3.1.2. Certificate manager must not exist during an installation

Certificate manager must not exist on a cluster when you install Red Hat Advanced Cluster Management for Kubernetes.

When certificate manager already exists on the cluster, Red Hat Advanced Cluster Management for Kubernetes installation fails.

To resolve this issue, verify if the certificate manager is present in your cluster by running the following command:

kubectl get crd | grep certificates.certmanager

1.3.2. Web console known issues

1.3.2.1. Node discrepancy between Cluster page and search results

You might see a discrepancy between the nodes dispalyed on the Cluster page and the Search results.

1.3.2.2. LDAP user names are case-sensitive

LDAP user names are case-sensitive. You must use the name exactly the way it is configured in your LDAP directory.

1.3.2.3. Console features might not display in Firefox earlier versions

The product supports Mozilla Firefox 74.0 or the latest version that is available for Linux, macOS, and Windows. Upgrade to the latest version for the best console compatibility.

1.3.2.4. Unable to search using values with empty spaces

From the console and Visual Web Terminal, users are unable to search for values that contain an empty space.

1.3.2.5. At logout user kubeadmin gets extra browser tab with blank page

When you are logged in as kubeadmin and you click the Log out option in the drop-down menu, the console returns to the login screen, but a browser tab opens with a /logout URL. The page is blank and you can close the tab without impact to your console.

1.3.2.6. Secret content is no longer displayed

For security reasons, search does not display the contents of secrets found on managed clusters. When you search for a secret from the console, you might receive the following error message:

Unable to load resource data - Check to make sure the cluster hosting this resource is online

1.3.2.7. Restrictions for storage size in searchcustomization

When you update the storage size in the searchcustomization CR, the PVC configuration does not change. If you need to update the storage size, update the PVC (<storageclassname>-search-redisgraph-0) with the following command:

oc edit pvc <storageclassname>-search-redisgraph-0

1.3.2.8. Observability endpoint operator fails to pull image

The observability endpoint operator fails if you create a pull-secret to deploy to the MultiClusterObservability CustomResource (CR) and there is no pull-secret in the open-cluster-management-observability namespace. When you import a new cluster, or import a Hive cluster that is created with Red Hat Advanced Cluster Management, you need to manually create a pull-image secret on the managed cluster.

For more information, see Enabling observability.

1.3.2.9. Observability add-on stuck in terminating

When the managed cluster is detached forcefully, the ObservabilityAddon resource (observability-addon) in the cluster namespace is stuck in the Terminating status and cannot be removed. Also, the cluster namespace cannot be deleted.

To fix this problem, you can update the ObervabilityAddon resource in the cluster namespace. Update the resource by deleting the finalizers parameter in the metadata. Run the following command:

kubectl edit observabilityaddon observability-addon -n <CLUSTER_NAMESPACE>

CLUSTER_NAMESPACE is the cluster namespace for the detached cluster.

After the finalizers parameter is removed, the ObervabilityAddon resource is removed.

1.3.3. Cluster management known issues

1.3.3.1. Cannot create bare metal managed clusters on OpenShift Container Platform version 4.7

You cannot create bare metal managed clusters by using the Red Hat Advanced Cluster Management hub cluster when the hub cluster is hosted on OpenShift Container Platform version 4.7.

1.3.3.2. Create resource dropdown error

When you detach a managed cluster, the Create resources page might temporarily break and display the following error:

Error occurred while retrieving clusters info. Not found.

Wait until the namespace automatically gets removed, which takes 5-10 minutes after you detach the cluster. Or, if the namespace is stuck in a terminating state, you need to manually delete the namespace. Return to the page to see if the error resolved.

1.3.3.3. Hub cluster and managed clusters clock not synced

Hub cluster and manage cluster time might become out-of-sync, displaying in the console unknown and eventually available within a few minutes. Ensure that the Red Hat OpenShift Container Platform hub cluster time is configured correctly. See Customizing nodes.

1.3.3.4. Console might report managed cluster policy inconsistency

After a cluster is imported, log in to the imported cluster and make sure all pods that are deployed by the Klusterlet are running. Otherwise, you might see inconsistent data in the console.

For example, if a policy controller is not running, you might not get the same results of violations on the Governance and risk page and the Cluster status.

For instance, you might see 0 violations listed in the Overview status, but you might have 12 violations reported on the Governance and risk page.

In this case, inconsistency between the pages represents a disconnection between the policy-controller-addon on managed clusters and the policy controller on the hub cluster. Additionally, the managed cluster might not have enough resources to run all the Klusterlet components.

As a result, the policy was not propagated to managed cluster, or the violation was not reported back from managed clusters.

1.3.3.5. Importing clusters might require two attempts

When you import a cluster that was previously managed and detached by a Red Hat Advanced Cluster Management hub cluster, the import process might fail the first time. The cluster status is pending import. Run the command again, and the import should be successful.

1.3.3.6. Importing certain versions of IBM Red Hat OpenShift Kubernetes Service clusters is not supported

You cannot import IBM Red Hat OpenShift Kubernetes Service version 3.11 clusters. Later versions of IBM OpenShift Kubernetes Service are supported.

1.3.3.7. Detaching OpenShift Container Platform 3.11 does not remove the open-cluster-management-agent

When you detach managed clusters on OpenShift Container Platform 3.11, the open-cluster-management-agent namespace is not automatically deleted. Manually remove the namespace by running the following command:

oc delete ns open-cluster-management-agent

1.3.3.8. Automatic secret updates for provisioned clusters is not supported

When you change your cloud provider access key, the provisioned cluster access key is not updated in the namespace. This is required when your credentials expire on the cloud provider where the managed cluster is hosted and you try delete the managed cluster. If something like this occurs, run the following command for your cloud provider to update the access key:

  • Amazon Web Services (AWS)

    oc patch secret {CLUSTER-NAME}-aws-creds -n {CLUSTER-NAME} --type json -p='[{"op": "add", "path": "/stringData", "value":{"aws_access_key_id": "{YOUR-NEW-ACCESS-KEY-ID}","aws_secret_access_key":"{YOUR-NEW-aws_secret_access_key}"} }]'
  • Google Cloud Platform (GCP)

    You can identify this issue by a repeating log error message that reads, Invalid JWT Signature when you attempt to destroy the cluster. If your log contains this message, obtain a new Google Cloud Provider service account JSON key and enter the following command:

    oc set data secret/<CLUSTER-NAME>-gcp-creds -n <CLUSTER-NAME> --from-file=osServiceAccount.json=$HOME/.gcp/osServiceAccount.json

    Replace CLUSTER-NAME with the name of your cluster.

    Replace the path to the file $HOME/.gcp/osServiceAccount.json with the path to the file that contains your new Google Cloud Provider service account JSON key.

  • Microsoft Azure

    oc set data secret/{CLUSTER-NAME}-azure-creds -n {CLUSTER-NAME} --from-file=osServiceAccount.json=$HOME/.azure/osServiceAccount.json
  • VMware vSphere

    oc patch secret {CLUSTER-NAME}-vsphere-creds -n {CLUSTER-NAME} --type json -p='[{"op": "add", "path": "/stringData", "value":{"username": "{YOUR-NEW-VMware-username}","password":"{YOUR-NEW-VMware-password}"} }]'

1.3.3.9. Cannot run management ingress as non-root user

You must be logged in as root to run the management-ingress service.

1.3.3.11. Process to destroy a cluster does not complete

When you destroy a managed cluster, the status continues to display Destroying after one hour, and the cluster is not destroyed. To resolve this issue complete the following steps:

  1. Manually ensure that there are no orphaned resources on your cloud, and that all of the provider resources that are associated with the managed cluster are cleaned up.
  2. Open the ClusterDeployment information for the managed cluster that is being removed by entering the following command:

    oc edit clusterdeployment/<mycluster> -n <namespace>

    Replace mycluster with the name of the managed cluster that you are destroying.

    Replace namespace with the namespace of the managed cluster.

  3. Remove the hive.openshift.io/deprovision finalizer to forcefully stop the process that is trying to clean up the cluster resources in the cloud.
  4. Save your changes and verify that ClusterDeployment is gone.
  5. Manually remove the namespace of the managed cluster by running the following command:

    oc delete ns <namespace>

    Replace namespace with the namespace of the managed cluster.

1.3.3.12. Cannot upgrade OpenShift Container Platform managed clusters on Red Hat OpenShift Dedicated with the console

You cannot use the Red Hat Advanced Cluster Management console to upgrade OpenShift Container Platform managed clusters that are in the Red Hat OpenShift Dedicated environment.

1.3.3.13. Metrics are unavailable in the Grafana console

  • Annotation query failed in the Grafana console:

    When you search for a specific annotation in the Grafana console, you might receive the following error message due to an expired token:

    "Annotation Query Failed"

    Refresh your browser and verify you are logged into your hub cluster.

  • Error in rbac-query-proxy pod:

    Due to unauthorized access to the managedcluster resource, you might receive the following error when you query a cluster or project:

    no project or cluster found

    Check the role permissions and update appropriately. See Role-based access control for more information.

1.3.3.14. Related bare metal assets not destroyed after bare metal cluster is destroyed

Your bare metal asset might remain as an orphaned asset after you destroy the cluster that was associated with it. This happens when you have the required permissions to destroy a cluster, but not to destroy the bare metal asset. To ensure that you do not experience this issue, add a finalizer to the ClusterDeployment resource when you create a bare metal asset with Red Hat Advanced Cluster Management that references a cluster deployment:

kubectl patch clusterdeployments <name> -n <namespace> -p '{"metadata":{"finalizers":["baremetalasset.inventory.open-cluster-management.io"]}}'

Replace name with the name of your cluster deployment.

Replace namespace with the namespace of your cluster resource.

If you delete the cluster deployment, you must remove the finalizer manually by entering the following command:

kubectl patch clusterdeployments <name> -n <namespace> -p '{"metadata":{"finalizers":[]}}'

Replace name with the name of your cluster deployment.

Replace namespace with the namespace of your cluster resource.

1.3.4. Application management known issues

1.3.4.1. Deployable resource with empty specification does not work

Applying a Deployable resource with no specification crashes the pod multicluster-operators-application container multicluster-operators-deployable. A deployable needs to contain specifications.

If you accidentally create the resource without a specification, delete the unnecessary deployable and restart the multicluster-operators-application pod.

See the following example of a Deployable that is empty and crashes the pod:

apiVersion: apps.open-cluster-management.io/v1
kind: Deployable
metadata:
  labels:
    app: simple-app-tester
  name: simple-app-tester-deployable
  namespace: grp-proof-of-concept-acm

1.3.4.2. Topology ReplicationController or ReplicaSet resources missing

When you deploy an application that directly creates a ReplicationController or ReplicaSet resource, the Pod resources are not displayed in the Application topology. You can use the Deployment or DeploymentConfig resources instead for creating Pod resources.

1.3.4.3. Application topology displays incorrect Ansible job status

Ansible tests run as hooks for the subscription and not as regular tasks. You need to store Ansible tasks in a prehook and posthook folder. You can choose to deploy the Ansible tasks as regular tasks and not as hooks, but the Application topology Ansible job status is not reported correctly in this case.

1.3.4.4. Application Ansible hook stand-alone mode

Ansible hook stand-alone mode is not supported. To deploy Ansible hook on the hub cluster with a subscription, you might use the following subscription YAML:

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

However, this configuration might never create the Ansible instance, since the spec.placement.local:true has the subscription running on standalone mode. You need to create the subscription in hub mode.

  1. Create a placement rule that deploys to local-cluster. See the following sample:

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: <towhichcluster>
      namespace: hello-openshift
    spec:
      clusterSelector:
        matchLabels:
          local-cluster: "true" #this points to your hub cluster
  2. Reference that placement rule in your subscription. See the following:

    apiVersion: apps.open-cluster-management.io/v1
    kind: Subscription
    metadata:
      name: sub-rhacm-gitops-demo
      namespace: hello-openshift
    annotations:
      apps.open-cluster-management.io/github-path: myapp
      apps.open-cluster-management.io/github-branch: master
    spec:
      hooksecretref:
          name: toweraccess
      channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
      placement:
         placementRef:
            name: <towhichcluster>
            kind: PlacementRule

After applying both, you should see the Ansible instance created in your hub cluster.

1.3.4.5. Application Deploy on local cluster limitation

If you select Deploy on local cluster when you create or edit an application, the application Topology does not display correctly. Deploy on local cluster is the option to deploy resources on your hub cluster so that you can manage it as the local cluster, but this is not best practice for this release.

To resolve the issue, see the following procedure:

  1. Deselect the Deploy on local cluster option in the console.
  2. Select the Deploy application resources only on clusters matching specified labels option.
  3. Create the following label: local-cluster : 'true'.

1.3.4.6. Namespace channel subscription remains in failed state

When you subscribe to a namespace channel and the subscription remains in FAILED state after you fixed other associated resources such as channel, secret, ConfigMap, or placement rule, the namespace subscription is not continuously reconciled.

To force the subscription reconcile again to get out of FAILED state, complete the following steps:

  1. Log in to your hub cluster.
  2. Manually add a label to the subscription using the following command:
oc label subscriptions.apps.open-cluster-management.io the_subscription_name reconcile=true

1.3.4.7. Edit role for application error

A user performing in an Editor role should only have read or update authority on an application, but erroneously editor can also create and delete an application. Red Hat OpenShift Operator Lifecycle Manager default settings change the setting for the product. To workaround the issue, see the following procedure:

  1. Run oc edit clusterrole applications.app.k8s.io-v1beta1-edit -o yaml to open the application edit cluster role.
  2. Remove create and delete from the verbs list.
  3. Save the change.

1.3.4.8. Edit role for placement rule error

A user performing in an Editor role should only have read or update authority on an placement rule, but erroneously editor can also create and delete, as well. Red Hat OpenShift Operator Lifecycle Manager default settings change the setting for the product. To workaround the issue, see the following procedure:

  1. Run oc edit clusterrole placementrules.apps.open-cluster-management.io-v1-edit to open the application edit cluster role.
  2. Remove create and delete from the verbs list.
  3. Save the change.

1.3.4.9. Application not deployed after an updated placement rule

If applications are not deploying after an update to a placement rule, verify that the klusterlet-addon-appmgr pod is running. The klusterlet-addon-appmgr is the subscription container that needs to run on endpoint clusters.

You can run oc get pods -n open-cluster-management-agent-addon to verify.

You can also search for kind:pod cluster:yourcluster in the console and see if the klusterlet-addon-appmgr is running.

If you cannot verify, attempt to import the cluster again and verify again.

1.3.4.10. Subscription operator does not create an SCC

Learn about Red Hat OpenShift Container Platform SCC at Managing Security Context Constraints (SCC), which is an additional configuration required on the managed cluster.

Different deployments have different security context and different service accounts. The subscription operator cannot create an SCC automatically. Administrators control permissions for pods. A Security Context Constraints (SCC) CR is required to enable appropriate permissions for the relative service accounts to create pods in the non-default namespace:

To manually create an SCC CR in your namespace, complete the following:

  1. Find the service account that is defined in the deployments. For example, see the following nginx deployments:

     nginx-ingress-52edb
     nginx-ingress-52edb-backend
  2. Create an SCC CR in your namespace to assign the required permissions to the service account or accounts. See the following example where kind: SecurityContextConstraints is added:

     apiVersion: security.openshift.io/v1
     defaultAddCapabilities:
     kind: SecurityContextConstraints
     metadata:
       name: ingress-nginx
       namespace: ns-sub-1
     priority: null
     readOnlyRootFilesystem: false
     requiredDropCapabilities:
     fsGroup:
       type: RunAsAny
     runAsUser:
       type: RunAsAny
     seLinuxContext:
       type: RunAsAny
     users:
     - system:serviceaccount:my-operator:nginx-ingress-52edb
     - system:serviceaccount:my-operator:nginx-ingress-52edb-backend

1.3.4.11. Application channels require unique namespaces

Creating more than one channel in the same namespace can cause errors with the hub cluster.

For instance, namespace charts-v1 is used by the installer as a Helm type channel, so do not create any additional channels in charts-v1. Ensure that you create your channel in a unique namespace. All channels need an individual namespace, except GitHub channels, which can share a namespace with another GitHub channel.

1.3.5. Application management limitations

1.3.5.1. Application console tables

See the following limitations to various Application tables in the console:

  • From the Applications table on the Overview page, the Clusters column on each table displays a count of clusters where application resources are deployed. Since applications are defined by Application, Subscription, PlacementRule, and Channel objects on the local cluster, the local cluster is included in the search results, whether actual application resources are deployed on the local cluster or not.
  • From the Advanced configuration table for Subscriptions, the Applications column displays the total number of applications that use that subscription, but if the subscription deploys child applications, those are included in the search result, as well.
  • From the Advanced configuration table for Channels, the Subscriptions column displays the total number of subscriptions on the local cluster that use that channel, but this does not include subscriptions that are deployed by other subscriptions, which are included in the search result.

1.4. Deprecations and removals

Learn when parts of the product are deprecated or removed from Red Hat Advanced Cluster Management for Kubernetes.

Note: A stabilized item is not deprecated or removed from a release of a product, but is no longer updated or developed. For instance, if an API is replaced with a new version in a release, but no longer updated, it can be listed in this topic as stabilized. The API is still available for one to three more releases before deprecated or removed.

Consider the alternative actions in the Recommended action and details that are provided in a table only if stabilized functions are listed for the current release.

1.4.1. Deprecations

A deprecated component, feature, or service is supported, but no longer recommended for use and might become obsolete. Consider the alternative actions in the Recommended action and details that are provided in the following table:

Product or categoryAffected itemVersionRecommended actionMore details and links

Application management

HelmRepo channel specification: usage of insecureSkipVerify: "true" is no longer inside the configMapRef

2.2

Use insecureSkipVerify: "true" in the channel without the configMapRef

See the YAML sample for the change.

1.4.1.1. Guidance for API deprecations

Red Hat Advanced Cluster Management follows the Kubernetes deprecation guidelines for APIs. See the Kubernetes Deprecation Policy for more details about that policy.

Red Hat Advanced Cluster Management APIs are only deprecated or removed outside of the following timelines:

  • All V1 APIs are generally available and supported for 12 months or three releases, whichever is greater. V1 APIs are not removed, but can be deprecated outside of that time limit.
  • All beta APIs are generally available for nine months or three releases, whichever is greater. Beta APIs are not removed outside of that time limit.
  • All alpha APIs are not required to be supported, but might be listed as deprecated or removed if it benefits users.

1.4.2. Removals

A removed item is typically function that was deprecated in previous releases and is no longer available in the product. You must use alternative features as a replacement for the removed function. Consider the alternative actions in the Recommended action and details that are provided in the following table:

Product or categoryAffected itemVersionRecommended actionMore details and links

Observability Topology

Topology access from Observe environments removed completely

2.2

None

Application topology is located in Application management and no longer in the Observability console.

Application management

Channel type: Namespace, removed completely

2.2

None

None

1.5. Red Hat Advanced Cluster Management for Kubernetes platform considerations for GDPR readiness

1.5.1. Notice

This document is intended to help you in your preparations for General Data Protection Regulation (GDPR) readiness. It provides information about features of the Red Hat Advanced Cluster Management for Kubernetes platform that you can configure, and aspects of the product’s use, that you should consider to help your organization with GDPR readiness. This information is not an exhaustive list, due to the many ways that clients can choose and configure features, and the large variety of ways that the product can be used in itself and with third-party clusters and systems.

Clients are responsible for ensuring their own compliance with various laws and regulations, including the European Union General Data Protection Regulation. Clients are solely responsible for obtaining advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulations that may affect the clients' business and any actions the clients may need to take to comply with such laws and regulations.

The products, services, and other capabilities described herein are not suitable for all client situations and may have restricted availability. Red Hat does not provide legal, accounting, or auditing advice or represent or warrant that its services or products will ensure that clients are in compliance with any law or regulation.

1.5.2. Table of Contents

1.5.3. GDPR

General Data Protection Regulation (GDPR) has been adopted by the European Union ("EU") and applies from May 25, 2018.

1.5.3.1. Why is GDPR important?

GDPR establishes a stronger data protection regulatory framework for processing personal data of individuals. GDPR brings:

  • New and enhanced rights for individuals
  • Widened definition of personal data
  • New obligations for processors
  • Potential for significant financial penalties for non-compliance
  • Compulsory data breach notification

1.5.3.2. Read more about GDPR

1.5.4. Product Configuration for GDPR

The following sections describe aspects of data management within the Red Hat Advanced Cluster Management for Kubernetes platform and provide information on capabilities to help clients with GDPR requirements.

1.5.5. Data Life Cycle

Red Hat Advanced Cluster Management for Kubernetes is an application platform for developing and managing on-premises, containerized applications. It is an integrated environment for managing containers that includes the container orchestrator Kubernetes, cluster lifecycle, application lifecycle, and security frameworks (governance, risk, and compliance).

As such, the Red Hat Advanced Cluster Management for Kubernetes platform deals primarily with technical data that is related to the configuration and management of the platform, some of which might be subject to GDPR. The Red Hat Advanced Cluster Management for Kubernetes platform also deals with information about users who manage the platform. This data will be described throughout this document for the awareness of clients responsible for meeting GDPR requirements.

This data is persisted on the platform on local or remote file systems as configuration files or in databases. Applications that are developed to run on the Red Hat Advanced Cluster Management for Kubernetes platform might deal with other forms of personal data subject to GDPR. The mechanisms that are used to protect and manage platform data are also available to applications that run on the platform. Additional mechanisms might be required to manage and protect personal data that is collected by applications run on the Red Hat Advanced Cluster Management for Kubernetes platform.

To best understand the Red Hat Advanced Cluster Management for Kubernetes platform and its data flows, you must understand how Kubernetes, Docker, and the Operator work. These open source components are fundamental to the Red Hat Advanced Cluster Management for Kubernetes platform. You use Kubernetes deployments to place instances of applications, which are built into Operators that reference Docker images. The Operator contain the details about your application, and the Docker images contain all the software packages that your applications need to run.

1.5.5.1. What types of data flow through Red Hat Advanced Cluster Management for Kubernetes platform

As a platform, Red Hat Advanced Cluster Management for Kubernetes deals with several categories of technical data that could be considered as personal data, such as an administrator user ID and password, service user IDs and passwords, IP addresses, and Kubernetes node names. The Red Hat Advanced Cluster Management for Kubernetes platform also deals with information about users who manage the platform. Applications that run on the platform might introduce other categories of personal data unknown to the platform.

Information on how this technical data is collected/created, stored, accessed, secured, logged, and deleted is described in later sections of this document.

1.5.5.2. Personal data used for online contact

Customers can submit online comments/feedback/requests for information about in a variety of ways, primarily:

  • The public Slack community if there is a Slack channel
  • The public comments or tickets on the product documentation
  • The public conversations in a technical community

Typically, only the client name and email address are used, to enable personal replies for the subject of the contact, and the use of personal data conforms to the Red Hat Online Privacy Statement.

1.5.6. Data Collection

The Red Hat Advanced Cluster Management for Kubernetes platform does not collect sensitive personal data. It does create and manage technical data, such as an administrator user ID and password, service user IDs and passwords, IP addresses, and Kubernetes node names, which might be considered personal data. The Red Hat Advanced Cluster Management for Kubernetes platform also deals with information about users who manage the platform. All such information is only accessible by the system administrator through a management console with role-based access control or by the system administrator though login to a Red Hat Advanced Cluster Management for Kubernetes platform node.

Applications that run on the Red Hat Advanced Cluster Management for Kubernetes platform might collect personal data.

When you assess the use of the Red Hat Advanced Cluster Management for Kubernetes platform running containerized applications and your need to meet the requirements of GDPR, you must consider the types of personal data that are collected by the application and aspects of how that data is managed, such as:

  • How is the data protected as it flows to and from the application? Is the data encrypted in transit?
  • How is the data stored by the application? Is the data encrypted at rest?
  • How are credentials that are used to access the application collected and stored?
  • How are credentials that are used by the application to access data sources collected and stored?
  • How is data collected by the application removed as needed?

This is not a definitive list of the types of data that are collected by the Red Hat Advanced Cluster Management for Kubernetes platform. It is provided as an example for consideration. If you have any questions about the types of data, contact Red Hat.

1.5.7. Data storage

The Red Hat Advanced Cluster Management for Kubernetes platform persists technical data that is related to configuration and management of the platform in stateful stores on local or remote file systems as configuration files or in databases. Consideration must be given to securing all data at rest. The Red Hat Advanced Cluster Management for Kubernetes platform supports encryption of data at rest in stateful stores that use dm-crypt.

The following items highlight the areas where data is stored, which you might want to consider for GDPR.

  • Platform Configuration Data: The Red Hat Advanced Cluster Management for Kubernetes platform configuration can be customized by updating a configuration YAML file with properties for general settings, Kubernetes, logs, network, Docker, and other settings. This data is used as input to the Red Hat Advanced Cluster Management for Kubernetes platform installer for deploying one or more nodes. The properties also include an administrator user ID and password that are used for bootstrap.
  • Kubernetes Configuration Data: Kubernetes cluster state data is stored in a distributed key-value store, etcd.
  • User Authentication Data, including User IDs and passwords: User ID and password management are handled through a client enterprise LDAP directory. Users and groups that are defined in LDAP can be added to Red Hat Advanced Cluster Management for Kubernetes platform teams and assigned access roles. Red Hat Advanced Cluster Management for Kubernetes platform stores the email address and user ID from LDAP, but does not store the password. Red Hat Advanced Cluster Management for Kubernetes platform stores the group name and upon login, caches the available groups to which a user belongs. Group membership is not persisted in any long-term way. Securing user and group data at rest in the enterprise LDAP must be considered. Red Hat Advanced Cluster Management for Kubernetes platform also includes an authentication service, Open ID Connect (OIDC) that interacts with the enterprise directory and maintains access tokens. This service uses ETCD as a backing store.
  • Service authentication data, including user IDs and passwords: Credentials that are used by Red Hat Advanced Cluster Management for Kubernetes platform components for inter-component access are defined as Kubernetes Secrets. All Kubernetes resource definitions are persisted in the etcd key-value data store. Initial credentials values are defined in the platform configuration data as Kubernetes Secret configuration YAML files. For more information, see Managing secrets.

1.5.8. Data access

Red Hat Advanced Cluster Management for Kubernetes platform data can be accessed through the following defined set of product interfaces.

  • Web user interface (the console)
  • Kubernetes kubectl CLI
  • Red Hat Advanced Cluster Management for Kubernetes CLI
  • oc CLI

These interfaces are designed to allow you to make administrative changes to your Red Hat Advanced Cluster Management for Kubernetes cluster. Administration access to Red Hat Advanced Cluster Management for Kubernetes can be secured and involves three logical, ordered stages when a request is made: authentication, role-mapping, and authorization.

1.5.8.1. Authentication

The Red Hat Advanced Cluster Management for Kubernetes platform authentication manager accepts user credentials from the console and forwards the credentials to the backend OIDC provider, which validates the user credentials against the enterprise directory. The OIDC provider then returns an authentication cookie (auth-cookie) with the content of a JSON Web Token (JWT) to the authentication manager. The JWT token persists information such as the user ID and email address, in addition to group membership at the time of the authentication request. This authentication cookie is then sent back to the console. The cookie is refreshed during the session. It is valid for 12 hours after you sign out of the console or close your web browser.

For all subsequent authentication requests made from the console, the front-end NGINX server decodes the available authentication cookie in the request and validates the request by calling the authentication manager.

The Red Hat Advanced Cluster Management for Kubernetes platform CLI requires the user to provide credentials to log in.

The kubectl and oc CLI also requires credentials to access the cluster. These credentials can be obtained from the management console and expire after 12 hours. Access through service accounts is supported.

1.5.8.2. Role Mapping

Red Hat Advanced Cluster Management for Kubernetes platform supports role-based access control (RBAC). In the role mapping stage, the user name that is provided in the authentication stage is mapped to a user or group role. The roles are used when authorizing which administrative activities can be carried out by the authenticated user.

1.5.8.3. Authorization

Red Hat Advanced Cluster Management for Kubernetes platform roles control access to cluster configuration actions, to catalog and Helm resources, and to Kubernetes resources. Several IAM (Identity and Access Management) roles are provided, including Cluster Administrator, Administrator, Operator, Editor, Viewer. A role is assigned to users or user groups when you add them to a team. Team access to resources can be controlled by namespace.

1.5.8.4. Pod Security

Pod security policies are used to set up cluster-level control over what a pod can do or what it can access.

1.5.9. Data Processing

Users of Red Hat Advanced Cluster Management for Kubernetes can control the way that technical data that is related to configuration and management is processed and secured through system configuration.

Role-based access control (RBAC) controls what data and functions can be accessed by users.

Data-in-transit is protected by using TLS. HTTPS (TLS underlying) is used for secure data transfer between user client and back end services. Users can specify the root certificate to use during installation.

Data-at-rest protection is supported by using dm-crypt to encrypt data.

These same platform mechanisms that are used to manage and secure Red Hat Advanced Cluster Management for Kubernetes platform technical data can be used to manage and secure personal data for user-developed or user-provided applications. Clients can develop their own capabilities to implement further controls.

1.5.10. Data Deletion

Red Hat Advanced Cluster Management for Kubernetes platform provides commands, application programming interfaces (APIs), and user interface actions to delete data that is created or collected by the product. These functions enable users to delete technical data, such as service user IDs and passwords, IP addresses, Kubernetes node names, or any other platform configuration data, as well as information about users who manage the platform.

Areas of Red Hat Advanced Cluster Management for Kubernetes platform to consider for support of data deletion:

  • All technical data that is related to platform configuration can be deleted through the management console or the Kubernetes kubectl API.

Areas of Red Hat Advanced Cluster Management for Kubernetes platform to consider for support of account data deletion:

  • All technical data that is related to platform configuration can be deleted through the Red Hat Advanced Cluster Management for Kubernetes or the Kubernetes kubectl API.

Function to remove user ID and password data that is managed through an enterprise LDAP directory would be provided by the LDAP product used with Red Hat Advanced Cluster Management for Kubernetes platform.

1.5.11. Capability for Restricting Use of Personal Data

Using the facilities summarized in this document, Red Hat Advanced Cluster Management for Kubernetes platform enables an end user to restrict usage of any technical data within the platform that is considered personal data.

Under GDPR, users have rights to access, modify, and restrict processing. Refer to other sections of this document to control the following:

  • Right to access

    • Red Hat Advanced Cluster Management for Kubernetes platform administrators can use Red Hat Advanced Cluster Management for Kubernetes platform features to provide individuals access to their data.
    • Red Hat Advanced Cluster Management for Kubernetes platform administrators can use Red Hat Advanced Cluster Management for Kubernetes platform features to provide individuals information about what data Red Hat Advanced Cluster Management for Kubernetes platform holds about the individual.
  • Right to modify

    • Red Hat Advanced Cluster Management for Kubernetes platform administrators can use Red Hat Advanced Cluster Management for Kubernetes platform features to allow an individual to modify or correct their data.
    • Red Hat Advanced Cluster Management for Kubernetes platform administrators can use Red Hat Advanced Cluster Management for Kubernetes platform features to correct an individual’s data for them.
  • Right to restrict processing

    • Red Hat Advanced Cluster Management for Kubernetes platform administrators can use Red Hat Advanced Cluster Management for Kubernetes platform features to stop processing an individual’s data.

1.5.12. Appendix

As a platform, Red Hat Advanced Cluster Management for Kubernetes deals with several categories of technical data that could be considered as personal data, such as an administrator user ID and password, service user IDs and passwords, IP addresses, and Kubernetes node names. Red Hat Advanced Cluster Management for Kubernetes platform also deals with information about users who manage the platform. Applications that run on the platform might introduce other categories of personal data that are unknown to the platform.

This appendix includes details on data that is logged by the platform services.

Legal Notice

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.