mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
82 lines
4.8 KiB
Plaintext
82 lines
4.8 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * 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 the {OCM} 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.
|
|
|
|
[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 {OCM} 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
|
|
See link:https://www.openshift.com/products/dedicated/process-and-security#compliance[OpenShift Dedicated Process and Security Overview] for the latest compliance information.
|
|
|
|
[id="network-security_{context}"]
|
|
== Network security
|
|
With {product-title} on AWS, AWS provides a standard DDoS protection on all Load Balancers, called AWS Shield. This provides 95% protection against most commonly used level 3 and 4 attacks on all the public facing Load Balancers used for {product-title}. A 10-second timeout is added for HTTP requests coming to the haproxy router to receive a response or the connection is closed to provide additional protection.
|
|
|
|
[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.
|
|
====
|