libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases 1 Packages Activity Actions

[KEYCLOAK-9361] Drop multiple (commented out) subsections from the

Browse source 
Get Started section

* 'Configuring Keystores' one (covered as 'Creating HTTPS and JGroups Keystores, ...'
  in Advanced Concepts section),
* 'Generating Secrets' one (covered as 'Secrets' subsection in Advanced Concepts),
* 'Creating the Service Account' one. Not needed at all (OCP 3.10 and 3.11 doesn't
   need it anymore),
* 'Using the OpenShift Web Console' one (covered as 'Deploying the Chosen {project_name}
   Passthrough TLS Template...' in Advanced Concepts sections, together with providing
   real expected values for these variables),
* 'Routes' one (since RH-SSO 7.3 doesn't use Passthrough TLS by default any more. The
   various supported TLS (reencrypt, passthrough) are described in
  '1.1. What Is Red Hat Single Sign-On?' section)

Signed-off-by: Jan Lieskovsky <jlieskov@redhat.com>
This commit is contained in:
Jan Lieskovsky 2019-01-21 20:25:45 +01:00 committed by Hynek Mlnařík
parent 0661424bd3
commit d764ed3fa1
1 changed files with 0 additions and 125 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

125
openshift/topics/get_started.adoc
View file

@ -169,131 +169,6 @@ and access the {project_name} administrator console at:
using the xref:sso-administrator-setup[administrator account].
////
=== Preparing and Deploying the {project_openshift_product_name} Application Templates
[[Configuring-Keystores]]
==== Configuring Keystores
The {project_openshift_product_name} image requires two keystores: +
- An SSL keystore to provide private and public keys for https traffic encryption. +
- A JGroups keystore to provide private and public keys for network traffic encryption between nodes in the cluster.
These keystores are expected by the {project_openshift_product_name} image, even if the application uses only http on a single-node OpenShift instance. Self-signed certificates do not provide secure communication and are intended for internal testing purposes.
[WARNING]
For production environments Red Hat recommends that you use your own SSL certificate purchased from a verified Certificate Authority (CA) for SSL-encrypted connections (HTTPS).
See the https://access.redhat.com/documentation/en-us/jboss_enterprise_application_platform/6.1/html-single/security_guide/index#Generate_a_SSL_Encryption_Key_and_Certificate[JBoss Enterprise Application Platform Security Guide] for more information on how to create a keystore with self-signed or purchased SSL certificates.
==== Generating Secrets
OpenShift uses objects called `Secrets` to hold sensitive information, such as passwords or keystores. See the https://access.redhat.com/documentation/en-us/openshift_enterprise/3.2/html-single/developer_guide/index#dev-guide-secrets[Secrets chapter] in the OpenShift documentation for more information.
The {project_openshift_product_name} image requires one or more secrets that hold the two keystores described earlier. This provides the necessary authorization to applications in the project.
Use the SSL and JGroups keystore files to create secrets for the project:
[source,bash,subs="attributes+,macros+"]
----
$ oc secret new <pass:quotes[_sso-ssl-secret_]> <pass:quotes[_ssl.jks_]>
$ oc secret new <pass:quotes[_sso-jgroups-secret_]> <pass:quotes[_jgroups.jceks_]>
----
////
////
==== Creating the Service Account
Service accounts are API objects that exist within each project and allow users to associate certain secrets and roles with applications in a project namespace. This provides the application with the necessary authorization to run with all required privileges.
The service account that you create must be configured with the correct permissions to view pods in Kubernetes. This is required in order for clustering with the {project_openshift_product_name} image to work. You can view the top of the log files to see whether the correct service account permissions have been configured.
. Create a service account to be used for the SSO deployment:
+
[source,bash,subs="attributes+,macros+"]
----
$ oc create serviceaccount <pass:quotes[_service-account-name_]>
----
. Add the *view* role to the service account. This enables the service account to view all the resources in the application namespace in OpenShift, which is necessary for managing the cluster.
+
[source,bash,subs="attributes+,macros+"]
----
$ oc policy add-role-to-user view system:serviceaccount:<pass:quotes[_project-name_]>:<pass:quotes[_service-account-name_]> -n <pass:quotes[_project-name_]>
----
. Link the secrets created for the project to the service account:
+
[source,bash,subs="attributes+,macros+"]
----
$ oc secrets link <pass:quotes[_service-account-name_]> <pass:quotes[_sso-ssl-secret_]> <pass:quotes[_sso-jgroups-secret_]>
----
==== Using the OpenShift Web Console
Log in to the OpenShift web console:
. Click *Add to project* to list the default image streams and templates.
. Use the *Filter by keyword* search bar to limit the list to those that match _sso_. You may need to click *See all* to show the desired application template.
. Select an application template and configure the deployment parameters as required.
. Click *Create* to deploy the application template.
These are some of the more common variables to configure an {project_name} deployment:
[cols="2*", options="header"]
|===
|Variable
|Description
|*_APPLICATION_NAME_*
|The name for the {project_name} application.
|*_HOSTNAME_HTTPS_*
|Custom hostname for https service route. Leave blank for default hostname of _<application-name>.<project>.<default-domain-suffix>_
|*_HOSTNAME_HTTP_*
|Custom hostname for http service route. Leave blank for default hostname of _<application-name>.<project>.<default-domain-suffix>_
|*_HTTPS_KEYSTORE_*
|The name of the keystore file within the secret.
|*_HTTPS_PASSWORD_*
|The password for the keystore and certificate.
|*_HTTPS_SECRET_*
|The name of the secret containing the keystore file.
|*_JGROUPS_ENCRYPT_KEYSTORE_*
|The name of the JGroups keystore file within the secret.
|*_JGROUPS_ENCRYPT_PASSWORD_*
|The password for the JGroups keystore and certificate.
|*_JGROUPS_ENCRYPT_SECRET_*
|The name of the secret containing the JGroups keystore file.
|*_SSO_ADMIN_USERNAME_*
|Username of the administrator account for the `master` realm of the {project_name} server. *Required.* If no value is specified, it is auto generated and displayed as an OpenShift instructional message when the template is instantiated.
|*_SSO_ADMIN_PASSWORD_*
|Password of the administrator account for the `master` realm of the {project_name} server. *Required.* If no value is specified, it is auto generated and displayed as an OpenShift instructional message when the template is instantiated.
|*_SSO_REALM_*
|The name of an additional {project_name} realm to create during deployment.
|*_SSO_SERVICE_USERNAME_*
|{project_name} service user name to manage the realm.
|*_SSO_SERVICE_PASSWORD_*
|{project_name} service user password.
|===
See the xref:env_vars[Reference chapter] for a more comprehensive list of the {project_name} environment variables.
See the xref:Example-Deploying-SSO[Example Workflow: Preparing and Deploying the {project_openshift_product_name} Image] for an end-to-end example of {project_name} deployment.
==== Routes
The {project_openshift_product_name} templates use TLS passthrough termination for routes by default. This means that the destination route receives encrypted traffic without the OpenShift router providing TLS termination. Users do not need the relevant SSL certificate to connect to the {project_name} login page.
For more information on OpenShift route types, see the link:https://docs.openshift.com/container-platform/3.7/architecture/networking/routes.html#route-types[Networking chapter] of the OpenShift Architecture Guide.
////
=== Binary Builds
To deploy existing applications on OpenShift, you can use the link:https://docs.openshift.com/container-platform/latest/dev_guide/builds/build_inputs.html#binary-source[binary source] capability.