Post install configuration

Step 1: GitLab omni auth oauth2 configuration

For using Keycloak as identity provider for GitLab authorization the following steps are necessary:

Create a Keycloak client for GitLab omni auth config

For the omni auth configuration of GitLab a new Keycloak client with name gilab-client has to be created. The following options have to be set:

Standard Flow Enabled: ON
Implicit Flow Enabled: ON
Direct Access Grants Enabled: ON
Service Accounts Enabled: ON
Authorization Enabled: ON
Valid Redirect URIs: <GITLAB_URI>/*
Web Origins : <GITLAB_URI>

Note: The notion of <GITLAB_URI> refers to the URL, where GitLab is available in your cluster.

Please ensure that there is a Token mapper of type User Property in place that places the username property as a claim named username in the JWT token.

Create omni auth config secret

Note: Please note that the following steps might differ depending on your GitLab version and edition.

The following steps show how to enable the OAuth authorization using Keycloak as identity provider:

Define the configuration of the OAuth authorization and save it in an environment variable:

OMNI_AUTH_CFG="name: 'oauth2_generic'
app_id: 'gitlab-client'
app_secret: '<KEYCLOAK_CLIENT_SECRET of the GitLab-client>
'args:  
   client_options:
     site: 'https://<KEYCLOAK_HOST>'
     user_info_url: '/auth/realms/<KEYCLOAK_REALM>/protocol/openid-connect/userinfo'
     authorize_url: '/auth/realms/<KEYCLOAK_REALM>/protocol/openid-connect/auth'
     token_url: '/auth/realms/<KEYCLOAK_REALM>/protocol/openid-connect/token' 
   user_response_structure:
     id_path: 'sub'
     attributes:
       name: 'name'
       email: 'email'
       nickname: 'username'
       first_name: 'given_name'
       last_name: 'family_name'"

Create a secret containing the omni-auth config. The secret must be named gitlab-config-omniauth-oauth2 and should contain on key named provider with the previously created content.
```
oc create secret generic -n "${GITLAB_NAMESPACE}" \
"gitlab-config-omniauth-oauth2" --type="Opaque" \
--from-literal="provider"="${OMNI_AUTH_CFG}"
```
Configure the GitLab to honour the additional provider. This can be done via specifying the parameters in the GitLab helm charts. For further information please see the official GitLab documentation.

Example:
```
omniauth:
  enabled: true
  providers:
   - secret: gitlab-config-omniauth-oauth2
     key: oauth2_generic
                  
                  
```

Note: The environment variable ${GITLAB_NAMESPACE} refers to the namespace, where GitLab was installed.

Step 2: Create an additional GitLab runner image pull secret

The GitLab runner needs a specific image pull secret for pulling the pipeline related images. For that a secret named runner-dockercfg-secret has to be created. This secret must contain the .dockercfg for the used docker registry (usually the internal OpenShift docker registry).

The DOCKER_CFG for the internal registry can be found and copied from an already existing dockercfg secrets in the cpd namespace. The best natural match is the dockercfg of the serviceaccount cpd-viewer-sa:

SECRET_NAME=$(oc -n ${CPD_LITE_NAMESPACE} get sa cpd-viewer-sa -o jsonpath='{.imagePullSecrets[0].name}')
DOCKER_CFG=$(oc get secret -n "${CPD}" "${SECRET_NAME}" -o jsonpath='{.data.\.dockercfg}' | base64 -d)

The following comand can be used to create this secret:

oc create secret \
generic -n "${GITLAB_NAMESPACE}" "runner-dockercfg-secret" \
--type="kubernetes.io/dockercfg" \
--from-literal=".dockercfg"="${DOCKER_CFG}"

Note: The environment variable ${GITLAB_NAMESPACE} refers to the namespace, where GitLab was installed.

Note: The environment variable ${CPD_LITE_NAMESPACE} refers to the namespace, where cpd (and the Solution Hub) was installed.

Step 3: Configure users and the configuration management

The following configurations have to be done before the product is ready to use:

Creating an user to login into the components (see User Configuration)
Configuration of the pipeline in the configuration management (see Pipeline Configuration). At least adjust the setting of ADO_CI_RUNTIME_NAME to match the namespace of your created Solution Envoy.
Configuration of cluster wide resources in the configuration management (see Cluster wide configuration). Please ensure that you provide valid configurations for the helm repository and docker registry.
Configuration of the envoy in the configuration management (see Solution Envoy configuration). Please ensure that you register the envoy, add a deploy target configuration and a solution default configuration.