1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/sdpolicy-security.adoc
2024-01-02 21:17:43 +00:00

102 lines
5.5 KiB
Plaintext

// Module included in the following assemblies:
//
// * osd_architecture/osd_policy/osd-service-definition.adoc
[id="sdpolicy-security_{context}"]
= Security
This section provides information about the service definition for {product-title} security.
[id="auth-provider_{context}"]
== Authentication provider
Authentication for the cluster is configured as part of {cluster-manager-first} cluster creation process. OpenShift is not an identity provider, and all access to the cluster must be managed by the customer as part of their integrated solution. Provisioning multiple identity providers provisioned at the same time is supported. The following identity providers are supported:
* GitHub or GitHub Enterprise OAuth
* GitLab OAuth
* Google OAuth
* LDAP
* OpenID connect
[id="privileged-containers_{context}"]
== Privileged containers
Privileged containers are not available by default on {product-title}. The `anyuid` and `nonroot` Security Context Constraints are available for members of the `dedicated-admins` group, and should address many use cases. Privileged containers are only available for `cluster-admin` users.
[id="cluster-admin-user_{context}"]
== Customer administrator user
In addition to normal users, {product-title} provides access to an {product-title}-specific group called `dedicated-admin`. Any users on the cluster that are members of the `dedicated-admin` group:
* Have administrator access to all customer-created projects on the cluster.
* Can manage resource quotas and limits on the cluster.
* Can add and manage `NetworkPolicy` objects.
* Are able to view information about specific nodes and PVs in the cluster, including scheduler information.
* Can access the reserved `dedicated-admin` project on the cluster, which allows for the creation of service accounts with elevated privileges and also gives the ability to update default limits and quotas for projects on the cluster.
* Can install Operators from OperatorHub (`\*` verbs in all `*.operators.coreos.com` API groups).
[id="cluster-admin-role_{context}"]
== Cluster administration role
As an administrator of {product-title} with Customer Cloud Subscriptions (CCS), you have access to the `cluster-admin` role. While logged in to an account with the `cluster-admin` role, users have mostly unrestricted access to control and configure the cluster. There are some configurations that are blocked with webhooks to prevent destablizing the cluster, or because they are managed in {cluster-manager} and any in-cluster changes would be overwritten.
[id="project-self-service_{context}"]
== Project self-service
All users, by default, have the ability to create, update, and delete their projects. This can be restricted if a member of the `dedicated-admin` group removes the self-provisioner role from authenticated users:
[source,terminal]
----
$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
----
Restrictions can be reverted by applying:
[source,terminal]
----
$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth
----
[id="regulatory-compliance_{context}"]
== Regulatory compliance
{product-title} follows common industry best practices for security and controls. The certifications are outlined in the following table.
.Security and control certifications for {product-title}
[cols= "3,3,3",options="header"]
|===
| Compliance | {product-title} on AWS | {product-title} on GCP
| HIPAA Qualified | Yes (Only Customer Cloud Subscriptions) | Yes (Only Customer Cloud Subscriptions)
| ISO 27001 | Yes | Yes
| PCI DSS | Yes | Yes
| SOC 2 Type 2 | Yes | Yes
|===
//This table exists in policy-security-regulation-compliance.adoc file also.
[id="network-security_{context}"]
== Network security
Each {product-title} cluster is protected by a secure network configuration at the cloud infrastructure level using firewall rules (AWS Security Groups or Google Cloud Compute Engine firewall rules). {product-title} customers on AWS are also protected against DDoS attacks with link:https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html[AWS Shield Standard].
Similarly, all GCP load balancers and public IP addresses used by {product-title} on GCP are protected against DDoS attacks with link:https://cloud.google.com/armor/docs/managed-protection-overview[Google Cloud Armor Standard].
[id="etcd-encryption_{context}"]
== etcd encryption
In {product-title}, the control plane storage is encrypted at rest by default and this includes encryption of the etcd volumes. This storage-level encryption is provided through the storage layer of the cloud provider.
You can also enable etcd encryption, which encrypts the key values in etcd, but not the keys. If you enable etcd encryption, the following Kubernetes API server and OpenShift API server resources are encrypted:
* Secrets
* Config maps
* Routes
* OAuth access tokens
* OAuth authorize tokens
The etcd encryption feature is not enabled by default and it can be enabled only at cluster installation time. Even with etcd encryption enabled, the etcd key values are accessible to anyone with access to the control plane nodes or `cluster-admin` privileges.
[IMPORTANT]
====
By enabling etcd encryption for the key values in etcd, you will incur a performance overhead of approximately 20%. The overhead is a result of introducing this second layer of encryption, in addition to the default control plane storage encryption that encrypts the etcd volumes. Red Hat recommends that you enable etcd encryption only if you specifically require it for your use case.
====