// 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,openshift-dedicated[]
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`