Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Document TLS and crypto settings #4946

Merged
merged 1 commit into from
Aug 23, 2017
Merged

Document TLS and crypto settings #4946

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 92 additions & 3 deletions architecture/index.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -118,8 +118,9 @@ xref:additional_concepts/authentication.adoc#architecture-additional-concepts-au
credentials, and then xref:additional_concepts/authorization.adoc#architecture-additional-concepts-authorization[authorize]
them based on their role. Both developers and administrators can be
authenticated via a number of means, primarily
xref:additional_concepts/authentication.adoc#oauth[OAuth tokens] and SSL
certificate authorization.
xref:additional_concepts/authentication.adoc#oauth[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 (clients of the system) typically make REST API calls from a
xref:../cli_reference/index.adoc#cli-reference-index[client program] like `oc` or to the
Expand All @@ -138,11 +139,99 @@ checks for one or more of the roles assigned to the user (e.g., cluster
administrator or administrator of the current project) before allowing it to
continue.

ifdef::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
ifdef::openshift-origin,openshift-online,openshift-enterprise[]
Since every container that runs on the cluster is associated with a service
account, it is also possible to associate
xref:../dev_guide/secrets.adoc#dev-guide-secrets[secrets] to those service accounts and have them
automatically delivered into the container. This enables the infrastructure to
manage secrets for pulling and pushing images, builds, and the deployment
components, and also allows application code to easily leverage those secrets.
endif::[]

All communication channels with the REST API as well as between
xref:infrastructure_components/kubernetes_infrastructure.adoc#master-components[master components]
such as etcd and API server, are secured with
link:https://en.wikipedia.org/wiki/Transport_Layer_Security[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}.
xref:../install_config/certificate_customization.adoc#install-config-certificate-customization[Custom certificates]
for public hosts are supported as well. The internal PKI uses 2048 bit RSA keys
and SHA-256 signatures.
endif::[]

{product-title} uses Golang’s standard library implementation of crypto/tls and
does not depend on any external crypto and TLS libraries link:https://golang.org/pkg/crypto/tls/[crypto/tls].
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.
{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 (e.g. 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, can be enabled in server config.]
|no footnoteref:[tlsconfig]
|_maybe_ footnoteref:[otherclient,some internal clients like 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]
|===

.Enabled cipher suites of {product-title} server and `oc` command

The cipher suites list is 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