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:

global:
  appConfig:
    omniauth:
      allowBypassTwoFactor: []
      allowSingleSignOn:
        - oauth2_generic
      autoLinkLdapUser: false
      autoLinkSamlUser: false
      autoSignInWithProvider: null
      blockAutoCreatedUsers: false
      enabled: true
      externalProviders: []
      providers:
        - secret: gitlab-config-omniauth-oauth2
          key: provider
      syncProfileAttributes:
        - email
      syncProfileFromProvider: []

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

Step 2: Create an additional GitLab runner image pull secret

Create the imagePullSecret

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} 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} refers to the namespace, where cpd (and the Solution Hub) was installed.

Assign the secret to the serviceaccount

After you created the secret, please map the secret to the serviceaccount, that is used in the pipelinesteps.

This can be done via specifying the parameters in the GitLab helm charts. For further information please see the official GitLab documentation.

Example:

gitlab-runner:
  install: true
  rbac:
    create: false
    serviceAccountName: gitlab-runner
  runners:
    cache:
      cacheShared: true
      cacheType: s3
      s3BucketLocation: us-east-1
      s3BucketName: runner-cache
      s3CacheInsecure: false
      s3CachePath: gitlab-runner
    locked: false
    serviceAccountName: gitlab-runner
    imagePullSecrets:
      - runner-dockercfg-secret

Step 3: Create minio bucket for the solution helm charts

The solution pipeline (step publish-helm-chart) uses a specific bucket in the minio service to save the helm charts of the created solutions. The name of the bucket must fit with the configured bucket name in the Helm Repository Configuration (see variable s3.bucketName, default value: helm-charts-default).

Please open your installed minio service.
Create a new bucket with the according name (e.g. helm-charts-default).

Step 4: Create a GitLab user for a specific service-account

This step might not be necessary on older GitLab versions, where an email address is assigned automatically to new users

Login in into the GitLab with user root or any other administrative user
Navigate to the Admin area - Users
Add a new user by clicking New user
Create a user with
- Name: service-account-auto-devops-solution-controller-callback-client
- Username: service-account-auto-devops-solution-controller-callback-client
- Email: service-account-auto-devops-solution-controller-callback-client@domain.cloud
Create user
After creating the user, please edit it and assign an identity to it.
On the user's detail page, navigate to identities
Click on New identity
Add a new identity, where the provider points to oauth2_generic and the identifier refers to the Keycloak given id of this serviceaccount (client auto-devops-solution-controller-callback-client).
Save changes

Note: To find out the valid id for the needed identity you can use the Keycloak administration. Navigate to the realm, which is used for the environment, and see the details of the client auto-devops-solution-controller-callback-client. In the url of your browser, there is then included the id.

Step 4: 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.