mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
126 lines
5.0 KiB
Plaintext
126 lines
5.0 KiB
Plaintext
// Module included in the following assemblies:
|
||
//
|
||
// * orphaned
|
||
|
||
[id="security-overview_{context}"]
|
||
= Security in {product-title}
|
||
|
||
The {product-title} and Kubernetes APIs authenticate users who present
|
||
credentials and then authorizes them based on their role. Both developers and
|
||
administrators can be authenticated through a number of means, primarily
|
||
OAuth tokens and X.509 client certificates. OAuth tokens are signed with JSON
|
||
Web Algorithm _RS256_, which is RSA signature algorithm PKCS#1 v1.5 with SHA-256.
|
||
|
||
Developers, the clients of the system, typically make REST API calls from a
|
||
client program like `oc` or to the {product-title} web console through their browser.
|
||
Both methods use OAuth bearer tokens for most communication. Infrastructure components.
|
||
like nodes, use client certificates that are generated by the system that contain their
|
||
identities. Infrastructure components that run in containers use a token that is
|
||
associated with their service account to connect to the API.
|
||
|
||
Authorization is handled in the {product-title} policy engine, which defines
|
||
actions like `create pod` or `list services`, and groups them into roles in a
|
||
policy document. Roles are bound to users or groups by the user or group
|
||
identifier. When a user or service account attempts an action, the policy engine
|
||
checks for one or more of the roles assigned to the user, such as a cluster
|
||
administrator or administrator of the current project, before allowing it to
|
||
continue.
|
||
|
||
ifdef::openshift-origin,openshift-online,openshift-enterprise,openshift-webscale[]
|
||
Since every container that runs on the cluster is associated with a service
|
||
account, it is also possible to associate secrets to those service accounts and have them
|
||
automatically delivered into the container. This secret delivery enables the infrastructure to
|
||
manage secrets for pulling and pushing images, builds, and the deployment
|
||
components and also allows application code to use those secrets.
|
||
endif::[]
|
||
|
||
[id="architecture-overview-tls-support_{context}"]
|
||
== TLS Support
|
||
|
||
All communication channels with the REST API, as well as between master
|
||
components such as etcd and the API server, are secured with TLS. TLS provides
|
||
strong encryption, data integrity, and authentication of servers with X.509
|
||
server certificates and public key infrastructure.
|
||
ifdef::openshift-origin,openshift-enterprise[]
|
||
By default, a new internal PKI is created for each deployment of
|
||
{product-title}. The internal PKI uses 2048 bit RSA keys and SHA-256 signatures.
|
||
endif::[]
|
||
ifdef::openshift-origin,openshift-enterprise,openshift-webscale[]
|
||
Custom certificates for public hosts are supported as well.
|
||
endif::[]
|
||
|
||
{product-title} uses Golang’s standard library implementation of
|
||
link:https://golang.org/pkg/crypto/tls/[*crypto/tls*] and does not depend on any
|
||
external crypto and TLS libraries. Additionally, the client depends on external
|
||
libraries for GSSAPI authentication and OpenPGP signatures. GSSAPI is typically
|
||
provided by either MIT Kerberos or Heimdal Kerberos, which both use OpenSSL's
|
||
libcrypto. OpenPGP signature verification is handled by libgpgme and GnuPG.
|
||
|
||
The insecure versions SSL 2.0 and SSL 3.0 are unsupported and not available. The
|
||
{product-title} server and `oc` client only provide TLS 1.2 by default. TLS 1.0
|
||
and TLS 1.1 can be enabled in the server configuration. Both server and client
|
||
prefer modern cipher suites with authenticated encryption algorithms and perfect
|
||
forward secrecy. Cipher suites with deprecated and insecure algorithms such as
|
||
RC4, 3DES, and MD5 are disabled. Some internal clients, like LDAP
|
||
authentication, have less restrict settings with TLS 1.0 to 1.2 and more cipher
|
||
suites enabled.
|
||
|
||
.Supported TLS Versions
|
||
[cols="4*", options="header"]
|
||
|===
|
||
|TLS Version
|
||
|{product-title} Server
|
||
|`oc` Client
|
||
|Other Clients
|
||
|
||
|SSL 2.0
|
||
|Unsupported
|
||
|Unsupported
|
||
|Unsupported
|
||
|
||
|SSL 3.0
|
||
|Unsupported
|
||
|Unsupported
|
||
|Unsupported
|
||
|
||
|TLS 1.0
|
||
|No footnoteref:[tlsconfig,Disabled by default, but can be enabled in the server configuration.]
|
||
|No footnoteref:[tlsconfig]
|
||
|Maybe footnoteref:[otherclient,Some internal clients, such as the LDAP client.]
|
||
|
||
|TLS 1.1
|
||
|No footnoteref:[tlsconfig]
|
||
|No footnoteref:[tlsconfig]
|
||
|Maybe footnoteref:[otherclient]
|
||
|
||
|TLS 1.2
|
||
|*Yes*
|
||
|*Yes*
|
||
|*Yes*
|
||
|
||
|TLS 1.3
|
||
|N/A footnoteref:[tls13,TLS 1.3 is still under development.]
|
||
|N/A footnoteref:[tls13]
|
||
|N/A footnoteref:[tls13]
|
||
|===
|
||
|
||
The following list of enabled cipher suites of {product-title}'s server and `oc`
|
||
client are sorted in preferred order:
|
||
|
||
- `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`
|
||
- `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305`
|
||
- `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`
|
||
- `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
|
||
- `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`
|
||
- `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
|
||
- `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`
|
||
- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`
|
||
- `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA`
|
||
- `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA`
|
||
- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA`
|
||
- `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA`
|
||
- `TLS_RSA_WITH_AES_128_GCM_SHA256`
|
||
- `TLS_RSA_WITH_AES_256_GCM_SHA384`
|
||
- `TLS_RSA_WITH_AES_128_CBC_SHA`
|
||
- `TLS_RSA_WITH_AES_256_CBC_SHA`
|