IBM Cloud Docs
Security and compliance

Security and compliance

You can use built-in security features in IBM Cloud Satellite® for risk analysis and security protection. These features help you to protect your Satellite workloads that run on your location infrastructure and network communication.

Data security

Learn more about options to secure the data that you use for workloads in IBM Cloud Satellite.

What data is stored when I use Satellite? How can I use my own keys to encrypt my data?

See Securing your data in IBM Cloud Satellite.

What measures can I take to secure user access to data in my location?

Review the following ways that you can secure access to your location.

IBM operational access

Learn more about IBM operational access to your Satellite location and how to monitor IBM-initiated activities.

What automated access does IBM have to my location?

Operations such as host attachment, host assignment, and major and minor version updates for the Satellite location control plane hosts are controlled by automation through the IBM Cloud Satellite API server in IBM Cloud. The Satellite API server communicates with the management plane, which also exists in IBM Cloud, to make these changes in your location.

Regular maintenance and automation tooling accesses the masters of Satellite-enabled IBM Cloud service clusters in your location through the default openshift-api-<cluster_ID> Link endpoint. This endpoint allows the Red Hat OpenShift on IBM Cloud API to communicate with the master for the service cluster. For example, if you create a Red Hat OpenShift cluster to run applications in your location, all version updates for that cluster's master are automatically applied through the default openshift-api-<cluster_ID> Link endpoint for that cluster.

Updates to Satellite-enabled IBM Cloud services that are running on hosts in your location are initiated by the IBM Cloud team for that service. When a change is ready to be rolled out to a service, the Satellite-enabled IBM Cloud service team uses Satellite Config to upload a new version of the service to the subscription that the Satellite-enabled IBM Cloud service cluster is included in. When you apply the update by using Satellite Config, the control plane for the API server, which exists in IBM Cloud, deploys the update to the master of the Satellite-enabled IBM Cloud service cluster in your location through the default openshift-api-<cluster_ID> Link endpoint. The cluster master then applies the updates to the worker nodes in the cluster.

What access do IBM SREs have to my location control plane, including the masters of Satellite-enabled IBM Cloud service clusters?

The default satellite-healthcheck-<location_ID> Link endpoint allows the Satellite management plane to check the health of your location's control plane cluster, and alerts IBM Site Reliability Engineers (SREs) when manual intervention is required.

  • To manually resolve issues with your Satellite location infrastructure management, such as host assignment or attachment, IBM SREs use tooling to access the IBM Cloud Satellite API server. The Satellite API server communicates with the Satellite management plane in IBM Cloud.
  • To manually resolve issues with masters of Satellite-enabled IBM Cloud service clusters in your location, such as if the master fails to correctly deploy, IBM SREs use tooling to access the default openshift-api-<cluster_ID> Link endpoint for the master of the service cluster.

Note that tooling is controlled through the IBM Cloud region that your Satellite location is managed from.

What access do IBM SREs have to my data and workloads that run in my Satellite-enabled IBM Cloud service clusters?

Satellite Link uses a zero-trust model: IBM Cloud has no access to your workloads by default. Any management of infrastructure in your location that is initiated by IBM SREs occurs through the Satellite API server, which exists in IBM Cloud, and any management of Satellite-enabled IBM Cloud service cluster masters occurs through the default openshift-api-<cluster_ID> Link endpoint for that cluster.

The access through the openshift-api-<cluster_ID> endpoint is isolated from your workloads and the network connections, such as the Link endpoints, that your workloads use. The openshift-api-<cluster_ID> provides access only to the Satellite location control plane. IBM SREs have no access to the hosts that are assigned as worker nodes of your Satellite-enabled IBM Cloud service clusters, where you run workloads in your location, because no default Link endpoints are created for workloads that run on these worker nodes, and all SSH access is disabled as part of the host bootstrapping process.

How can I monitor and manage IBM access into my location?

Default Satellite Link endpoints are created for your location's control plane cluster and for any other Satellite-enabled services that you run in your location. These default Satellite Link endpoints are accessible only from within the IBM Cloud private network. To review these endpoints, see Default Link endpoints for IBM Cloud access to your Satellite location. You have full control over these default endpoints, including the ability to disable them. However, disabling these endpoints prevents your location from being fully managed and updated, and the endpoints cannot be removed.

Satellite Link provides built-in controls to help you restrict which clients can access endpoints, ensuring that there are no back door access points on your hosts. For more information, see Access and audit controls.

Additionally, you can configure auditing to monitor user-initiated events for Link endpoints. IBM Cloud Satellite integrates with IBM Cloud® Activity Tracker to collect and send audit events for all link endpoints in your location to your Activity Tracker instance. For example, after you set up event auditing, you can review all events that relate to the masters for the clusters that run in your location, including events that are initiated by IBM Cloud. To get started with auditing, see Auditing events for endpoint actions.

What happens if Satellite Link becomes unavailable? Can IBM still maintain my Satellite location?

Satellite Link depends on the underlying connectivity of your hosts' local network to monitor and maintain the managed services for your Satellite location. If Satellite Link become unavailable, any requested changes to your Satellite location, such as adding hosts or access control requests to IBM services through Cloud Identity and Access Management, are disrupted. After connectivity is restored, logs and events are sent to your IBM Log Analysis and IBM Cloud Activity Tracker instances.

Note that your on-location workloads continue to run independently even if the location's connectivity to IBM Cloud is unavailable. However, if any applications use a Link endpoint to communicate with IBM Cloud, communication between those apps and IBM Cloud is disrupted.

For more information about making your Satellite location highly available, see High availability and disaster recovery for IBM Cloud Satellite.

Digital certificates for Satellite hosts and domains

Let's Encrypt certificates are automatically generated for several IBM Cloud Satellite domains and hosts. Regular renewal of these certificates helps keep your Satellite components secure. To see the expiry dates for each certificate and understand whether you or IBM is responsible for regenerating the certificate, review the following table.

Certificates for Satellite domains and hosts
Component Example domain Certificate expiry Who regenerates How to regenerate
Default Red Hat OpenShift on IBM Cloud API endpoint (openshift-api-<cluster_ID>) for each Satellite-enabled IBM Cloud service cluster c-04.private.us-east.link.satellite.cloud.ibm.com 19800 hours (~2.26 years) You Regenerated during a cluster master refresh or cluster master update.
Default endpoints for IBM Cloud services (IAM, Object Storage, Monitoring, Log Analysis) m65f0b26d6c5f695647f5-6b64a6ccc9c596bf59a86625d8fa2202-c000.us-east.satellite.appdomain.cloud 90 days IBM The Link tunnel server regenerates the certificate, and the Link tunnel client automatically reboots to reflect the rotated certificate.
c000, c001, c002, and c003 subdomains for each location zone s7033baaa45e1ae1a1060-d603ff82e51c94176a53d44566df9d79-c000.us-south.satellite.appdomain.cloud 19800 hours (~2.26 years) You Regenerated during a cluster master refresh or cluster master update.
ce00 Ingress subdomains s7033baaa45e1ae1a1060-d603ff82e51c94176a53d44566df9d79-ce00.us-south.satellite.appdomain.cloud 90 days IBM Setting up Ingress.
Worker node connection to the API server 10.240.128.09 3 years You Update hosts that are assigned as worker nodes.
Satellite management plane API endpoint http://c103-1.containers.cloud.ibm.com/ 19800 hours (~2.26 years) IBM Regenerated during automated rollouts for major and minor version updates for the Satellite location management plane hosts.
Satellite management plane hosts
19800 hours (~2.26 years) IBM Update control plane hosts.

Platform compliance and certification

Learn more about compliance standards for the IBM Cloud Satellite service.

What compliance standards does the service meet?

See the Satellite FAQ for compliance standards.

Which areas of security compliance am I responsible for?

For an overview of who is responsible for particular cloud resources when using IBM Cloud Satellite, see the table in Overview of shared responsibilities. For a detailed description of areas in which responsibilities are shared between you and IBM for security and compliance, see Tasks for shared responsibilities: Security and regulation compliance.

What are the security compliance responsibilities of Satellite-enabled IBM Cloud services?

To see the security options and compliance standards of a Satellite-enabled IBM Cloud service, review the documentation for each Satellite-enabled IBM Cloud service. For example, for Red Hat OpenShift clusters, see What compliance standards does the service meet? in the Red Hat OpenShift on IBM Cloud documentation.