mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
129 lines
6.1 KiB
Plaintext
129 lines
6.1 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc
|
|
// * rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc
|
|
|
|
ifeval::["{context}" == "rosa-hcp-service-definition"]
|
|
:rosa-with-hcp:
|
|
endif::[]
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="rosa-sdpolicy-security_{context}"]
|
|
= Security
|
|
|
|
This section provides information about the service definition for
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title-first}
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}
|
|
endif::openshift-rosa-hcp[]
|
|
security.
|
|
|
|
[id="rosa-sdpolicy-auth-provider_{context}"]
|
|
== Authentication provider
|
|
Authentication for the cluster can be configured using either {cluster-manager-url} or cluster creation process or using the ROSA CLI, `rosa`. ROSA is not an identity provider, and all access to the cluster must be managed by the customer as part of their integrated solution. The use of multiple identity providers provisioned at the same time is supported. The following identity providers are supported:
|
|
|
|
- GitHub or GitHub Enterprise
|
|
- GitLab
|
|
- Google
|
|
- LDAP
|
|
- OpenID Connect
|
|
- htpasswd
|
|
|
|
[id="rosa-sdpolicy-privileged-containers_{context}"]
|
|
== Privileged containers
|
|
Privileged containers are available for users with the `cluster-admin` role. Usage of privileged containers as `cluster-admin` is subject to the responsibilities and exclusion notes in the link:https://www.redhat.com/en/about/agreements[Red{nbsp}Hat Enterprise Agreement Appendix 4] (Online Subscription Services).
|
|
|
|
[id="rosa-sdpolicy-customer-admin-user_{context}"]
|
|
== Customer administrator user
|
|
In addition to normal users,
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title-first}
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}
|
|
endif::openshift-rosa-hcp[]
|
|
provides access to a
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title}-specific
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
ROSA-specific
|
|
endif::openshift-rosa-hcp[]
|
|
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 the software catalog and perform all verbs in all `*.operators.coreos.com` API groups.
|
|
|
|
[id="rosa-sdpolicy-cluster-admin-role_{context}"]
|
|
== Cluster administration role
|
|
The administrator of
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title-first}
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}
|
|
endif::openshift-rosa-hcp[]
|
|
has default access to the `cluster-admin` role for your organization's cluster. While logged into an account with the `cluster-admin` role, users have increased permissions to run privileged security contexts.
|
|
|
|
[id="rosa-sdpolicy-project-self-service_{context}"]
|
|
== Project self-service
|
|
By default, all users 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="rosa-sdpolicy-regulatory-compliance_{context}"]
|
|
== Regulatory compliance
|
|
//removing conditionals and first sentence as rosa-with-hcp has now obtained compliance certifications
|
|
See the _Compliance_ table in _Understanding process and security for ROSA_ for the latest compliance information.
|
|
|
|
[id="rosa-sdpolicy-network-security_{context}"]
|
|
== Network security
|
|
With {product-title}, 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 ROSA. 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="rosa-sdpolicy-etcd-encryption_{context}"]
|
|
== etcd encryption
|
|
|
|
In {product-title}, the control plane storage is encrypted at rest by default, including encryption of the etcd volumes. This storage-level encryption is provided through the storage layer of the cloud provider.
|
|
|
|
ifdef::openshift-rosa-hcp[]
|
|
Customers can also opt to encrypt the etcd database at build time or provide their own custom AWS KMS keys for the purpose of encrypting the etcd database.
|
|
|
|
Etcd encryption will encrypt the following Kubernetes API server and OpenShift API server resources:
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
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:
|
|
endif::openshift-rosa-hcp[]
|
|
|
|
* Secrets
|
|
* Config maps
|
|
* Routes
|
|
* OAuth access tokens
|
|
* OAuth authorize tokens
|
|
|
|
ifndef::openshift-rosa-hcp[]
|
|
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{nbsp}Hat recommends that you enable etcd encryption only if you specifically require it for your use case.
|
|
====
|
|
endif::openshift-rosa-hcp[]
|
|
|
|
ifeval::["{context}" == "rosa-hcp-service-definition"]
|
|
:!rosa-with-hcp:
|
|
endif::[]
|