// Module included in the following assemblies:
//
// * osd_architecture/osd_policy/policy-responsibility-matrix.adoc

:_mod-docs-content-type: REFERENCE
[id="policy-shared-responsibility_{context}"]
= Shared responsibility matrix

[role="_abstract"]
The customer and Red{nbsp}Hat share responsibility for the monitoring and maintenance of an {product-title} cluster. This documentation illustrates the delineation of responsibilities by area and task.

[id="incident-operations-management_{context}"]
== Incident and operations management
The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.

[cols= "2a,3a,3a",options="header"]
|===

|Resource
|Red Hat responsibilities
|Customer responsibilities

|Application networking
|Monitor cloud load balancers and native OpenShift router service, and respond to alerts.
|* Monitor health of service load balancer endpoints.
* Monitor health of application routes, and the endpoints behind them.
* Report outages to Red Hat.

|Virtual networking
|* Monitor cloud load balancers, subnets, and public cloud components necessary for default platform networking, and respond to alerts.
* Monitor the Red Hat Management project in {GCP} and the Private Service Connect (PSC) attachments. ^[1]^
|Monitor network traffic that is optionally configured through VPC to VPC connection, VPN connection, or Direct connection for potential issues or security threats.

|===
1. Applies to {product-title} on {GCP} clusters with PSC only.

[id="change-management_{context}"]
== Change management
Red Hat is responsible for enabling changes to the cluster infrastructure and services that the customer will control, as well as maintaining versions for the control plane nodes, infrastructure nodes and services, and worker nodes. The customer is responsible for initiating infrastructure change requests and installing and maintaining optional services and networking configurations on the cluster, as well as all changes to customer data and customer applications.

[cols="2a,3a,3a",options="header"]
|===

|Resource
|Red Hat responsibilities
|Customer responsibilities


|Logging
|* Centrally aggregate and monitor platform audit logs.
* Provide and maintain a logging operator to enable the customer to deploy a logging stack for default application logging.
* Provide audit logs upon customer request.
|* Install the optional default application logging operator on the cluster.
* Install, configure, and maintain any optional app logging solutions, such as logging sidecar containers or third-party logging applications.
* Tune size and frequency of application logs being produced by customer applications if they are affecting the stability of the logging stack or the cluster.
* Request platform audit logs through a support case for researching specific incidents.

|Application networking
|* Set up public cloud load balancers. Provide the ability to set up private load balancers and up to one additional load balancer when required.
* Set up native OpenShift router service. Provide the ability to set the router as private and add up to one additional router shard.
* Install, configure, and maintain OVN-Kubernetes components for default internal pod traffic.
* Provide the ability for the customer to manage `NetworkPolicy` and `EgressNetworkPolicy` (firewall) objects.
|* Configure non-default pod network permissions for project and pod networks, pod ingress, and pod egress using `NetworkPolicy` objects.
* Use {cluster-manager-first} to request a private load balancer for default application routes.
* Use {cluster-manager} to configure up to one additional public or private router shard and corresponding load balancer.
* Request and configure any additional service load balancers for specific services.
* Configure any necessary DNS forwarding rules.

|Cluster networking
|* Set up cluster management components, such as public or private service endpoints and necessary integration with virtual networking components.
* Set up internal networking components required for internal cluster communication between worker, infrastructure, and control plane nodes.
|* Provide optional non-default IP address ranges for machine CIDR, service CIDR, and pod CIDR if needed through {cluster-manager} when the cluster is provisioned.
* Request that the API service endpoint be made public or private on cluster creation or after cluster creation through {cluster-manager}.

|Virtual networking
|* Set up and configure virtual networking components required to provision the cluster, including virtual private cloud, subnets, load balancers, internet gateways, NAT gateways, etc.
* Provide the ability for the customer to manage VPN connectivity with on-premise resources, VPC to VPC connectivity, and Direct connectivity as required through {cluster-manager}.
* Setup and configure PSC attachments. ^[1]^
* Enable customers to create and deploy public cloud load balancers for use with service load balancers.
|* Set up and maintain optional public cloud networking components, such as VPC to VPC connection, VPN connection, or Direct connection.
* Request and configure any additional service load balancers for specific services.
* Create a PSC subnet. ^[1]^

|Cluster version
|* Enable upgrade scheduling process.
* Monitor upgrade progress and remedy any issues encountered.
* Publish changelogs and release notes for minor and maintenance upgrades.
|* Schedule maintenance version upgrades either immediately, for the future, or have automatic upgrades.
* Acknowledge and schedule minor version upgrades.
* Ensure the cluster version stays on a supported minor version.
* Test customer applications on minor and maintenance versions to ensure compatibility.

|Capacity management
|* Monitor utilization of control plane (control plane nodes and infrastructure nodes).
* Scale or resize control plane nodes to maintain quality of service.
* Monitor utilization of customer resources including Network, Storage and Compute capacity. Where autoscaling features are not enabled alert customer for any changes required to cluster resources (for example, new compute nodes to scale, additional storage, etc).
|* Use the provided {cluster-manager} controls to add or remove additional worker nodes as required.
* Respond to Red Hat notifications regarding cluster resource requirements.

|===
1. Applies to {product-title} on {GCP} clusters with PSC only.

[id="identity-access-management_{context}"]
== Access and identity authorization
The access and identity authorization matrix includes responsibilities for managing authorized access to clusters, applications, and infrastructure resources. This includes tasks such as providing access control mechanisms, authentication, authorization, and managing access to resources.

[cols="2a,3a,3a",options="header"]
|===
|Resource
|Red Hat responsibilities
|Customer responsibilities

|Logging
|* Adhere to an industry standards-based tiered internal access process for platform audit logs.
* Provide native OpenShift RBAC capabilities.
|* Configure OpenShift RBAC to control access to projects and by extension a project’s application logs.
* For third-party or custom application logging solutions, the customer is responsible for access management.

|Application networking
|Provide native OpenShift RBAC and `dedicated-admin` capabilities.
|* Configure OpenShift dedicated-admins and RBAC to control access to route configuration as required.
* Manage Org Admins for Red Hat organization to grant access to {cluster-manager}. {cluster-manager} is used to configure router options and provide service load balancer quota.

|Cluster networking
|* Provide customer access controls through {cluster-manager}.
* Provide native OpenShift RBAC and `dedicated-admin` capabilities.
|* Manage Red Hat organization membership of Red Hat accounts.
* Manage Org Admins for Red Hat organization to grant access to {cluster-manager}.
* Configure OpenShift dedicated-admins and RBAC to control access to route configuration as required.

|Virtual networking
|Provide customer access controls through {cluster-manager}.
|Manage optional user access to public cloud components through {cluster-manager}.

|===

[id="security-regulation-compliance_{context}"]
== Security and regulation compliance
The following are the responsibilities and controls related to compliance:

[cols="2a,3a,3a",options="header"]
|===

|Resource
|Red Hat responsibilities
|Customer responsibilities

|Logging
|Send cluster audit logs to a Red Hat SIEM to analyze for security events. Retain audit logs for a defined period of time to support forensic analysis.
|Analyze application logs for security events. Send application logs to an external endpoint through logging sidecar containers or third-party logging applications if longer retention is required than is offered by the default logging stack.

|Virtual networking
|* Monitor virtual networking components for potential issues and security threats.
* Leverage additional public cloud provider tools for additional monitoring and protection.
|* Monitor optionally-configured virtual networking components for potential issues and security threats.
* Configure any necessary firewall rules or data center protections as required.

|===

[id="disaster-recovery_{context}"]
== Disaster recovery
Disaster recovery includes data and configuration backup, replicating data and configuration to the disaster recovery environment, and failover on disaster events.


[cols="2a,3a,3a" ,options="header"]
|===
|Resource
|Red Hat responsibilities
|Customer responsibilities

|Virtual networking
|Restore or recreate affected virtual network components that are necessary for the platform to function.
|* Configure virtual networking connections with more than one tunnel where possible for protection against outages as recommended by the public cloud provider.
* Maintain failover DNS and load balancing if using a global load balancer with multiple clusters.

|===
