Skip to content

Latest commit

 

History

History
200 lines (139 loc) · 11.4 KB

configuration.md

File metadata and controls

200 lines (139 loc) · 11.4 KB
Raw

Configuration

GitLab in this package is configured through the upstream GitLab chart as well as a UDS configuration chart that supports the following:

GitLab License

uds-gitlab-config chart:

  • license - Set this to the contents of a GitLab license file to enable GitLab Premium or Ultimate.

Networking

Network policies are controlled via the uds-gitlab-config chart in accordance with the common patterns for networking within UDS Software Factory. GitLab interacts with GitLab runners, object storage, Redis and Postgresql externally and supports the following keys:

  • storage: sets network policies for accessing object storage from all GitLab services (registry, pages, webservice, toolbox, sidekiq)
  • redis: sets network policies for accessing a Redis-compatible server from all GitLab services (webservice, toolbox, sidekiq, migrations, gitlab-exporter)
  • postgres: sets network policies for accessing a Postgres database from all GitLab services (webservice, toolbox, sidekiq, migrations, gitlab-exporter)
  • custom: sets custom network policies for the GitLab namespace - this allows for custom integrations with other services (i.e. Jira)

Note

Currently the GitLab UDS Package contains Istio PeerAuthentication exceptions to allow the dependency init containers to reach out and check the Redis and Postgres services. These are only added with redis.internal or postgres.internal set to true and will be removed once UDS Core switches to native sidecars.

Database

GitLab uses Postgres as its backing database service and supports the common database providers within UDS Software Factory.

Manual Database Connection

If you are using the UDS Postgres Operator or another external database that uses usernames/passwords you can use the following Helm overrides to configure it:

uds-gitlab-config chart:

Important

The postgres.password setting is not applicable when using the UDS Postgres Operator package or when supplying a secret manually!

  • postgres.password - provides a password to generate a secret to pass to GitLab

gitlab chart:

Important

The global.psql.password.secret and global.psql.password.key settings are not applicable when providing a password to the uds-gitlab-config chart manually.

  • global.psql.username - provides the username to use when connecting to the database (i.e. gitlab.gitlab)
  • global.psql.password.secret - provides the secret that contains the database password (defaults to gitlab-postgres)
  • global.psql.password.key - provides the secret key that contains the database password (defaults to password)
  • global.psql.host - provides the endpoint to use to connect to the database (i.e. pg-cluster.postgres.svc.cluster.local)
  • global.psql.port - provides the port to use to connect to the database (defaults to 5432)

IAM Roles for Service Accounts

The Software Factory team has not yet tested IRSA with AWS RDS - there is an open issue linked below with further linked issues to test this that could act as a starting point to implement:

defenseunicorns/uds-software-factory#45

Object Storage

Note

This section is subject to change / improvement once uds-package-minio-operator is fully ready for production use cases.

Object Storage works a bit differently as there are many kinds of file stores GitLab can be configured to use.

  • Create the secret gitlab-object-store in the gitlab namespace with the following keys:
    • An example for in-cluster Minio can be found in this repository at the path src/dev-secrets/minio-secret.yaml
    • connection
      • This key refers to the configuration for the main GitLab service. The documentation for what goes in this key is located here
    • registry
      • This key refers to the configuration for the gitlab registry. The documentation for what goes in this key is located here
    • backups
      • This key refers to the configuration for the gitlab-toolbox backup tool. It relies on a program called s3cmd. The documentation for what goes in this key is located here
  • Below are the list of buckets that need to be created before starting GitLab:
  - uds-gitlab-pages
  - uds-gitlab-registry
  - uds-gitlab-lfs
  - uds-gitlab-artifacts
  - uds-gitlab-uploads
  - uds-gitlab-packages
  - uds-gitlab-mr-diffs
  - uds-gitlab-terraform-state
  - uds-gitlab-ci-secure-files
  - uds-gitlab-dependency-proxy
  - uds-gitlab-backups
  - uds-gitlab-tmp
  • These buckets can have a suffix applied via the BUCKET_SUFFIX Zarf variable (e.g. -some-deployment-name plus uds-gitlab-backups would be uds-gitlab-backups-some-deployment-name)

Redis / Valkey

GitLab uses Redis as a key value store for caching, job queueing and more and supports external providers (such as Elasticache) as well as the UDS Valkey package to provide the service.

Manual Keystore Connection

You can use the following Helm overrides to configure a connection to Redis / Valkey:

uds-gitlab-config chart:

Important

The redis.password setting is not applicable when using the UDS Valkey package or when supplying a secret manually!

  • redis.password - provides a password to generate a secret to pass to GitLab

gitlab chart:

Important

The global.redis.auth.secret and global.redis.auth.key settings are not applicable when providing a password to the uds-gitlab-config chart manually.

  • global.redis.auth.secret - provides the secret that contains the key value store password (defaults to gitlab-redis)
  • global.redis.auth.key - provides the key within the secret that contains the key value store password (defaults to password)
  • global.redis.scheme - provides the scheme to use to connect to the key value store (i.e. redis or rediss)
  • global.redis.host - provides the endpoint to use to connect to the key value store (i.e. pg-cluster.postgres.svc.cluster.local)
  • global.redis.port - provides the port to use to connect to the key value store (defaults to 6379)

Configuring SSH

By default this package deploys GitLab in an HTTPS-only mode - this reduces the attack surface by removing one potential point of ingress, but if you need to enable SSH git cloning and have mitigated this risk in other ways you can do so with the following overrides:

uds-core package:

Before configuring the GitLab package to allow SSH traffic you will need to also allow the traffic through UDS Core (and everything before it). To configure UDS Core to pass through SSH you will need to add the following (where 2222 is replaced with your chosen SSH port):

    overrides:
      istio-tenant-gateway:
        gateway:
          values:
            - path: "service.ports"
              value:
                - name: status-port
                  port: 15021
                  protocol: TCP
                  targetPort: 15021
                - name: http2
                  port: 80
                  protocol: TCP
                  targetPort: 80
                - name: https
                  port: 443
                  protocol: TCP
                  targetPort: 443
                - name: tcp-ssh
                  port: 2222
                  protocol: TCP
                  targetPort: 2222

This will allow SSH traffic to traverse the LoadBalancer and hit the Istio Gateway that is configured in the GitLab chart.

uds-gitlab-config chart:

  • ssh.enabled - set this to true to enable the additional gateway and virtual service
  • ssh.port - set this to a different integer if you'd like to expose ssh over a different port (defaults to 2222)

gitlab chart:

  • gitlab.gitlab-shell.enabled - set this to true to enable the SSH daemon within the GitLab deployment
  • global.shell.port - set this if you overrode ssh.port above to correct the port for the gitlab-shell service and the UI (defaults to 2222)

uds-gitlab-settings chart:

  • settingsJob.application.enabled_git_access_protocol - set this to all to reenable the SSH option when selecting a repository's clone dropdown

Configuring GitLab Settings

This package contains an additional chart that will force GitLab application settings to take the values recommended in the GitLab Application Hardening Recommendations guide. These settings may need to be modified for your instance or you may wish to make tweaks to add additional settings that can be found in the GitLab Application Settings documentation.

It is recommended to inspect these settings and further lock them down for your specific environment if you are able. You can change or add settings by adding your desired key to the settingsJob.application value of the uds-gitlab-settings chart. This YAML object will be converted to a JSON object and then into query parameters to pass to the GitLab Application Settings API.

Important

Simple key-value pairs can be set as-is, however objects/arrays should be set to the values that would be expected as a query parameter. As an example, {"restricted_visibility_levels": ["public"]} becomes restricted_visibility_levels: public in the YAML object.

Tip

If you wish to disable the settings Job and CronJob and keep GitLab's default application settings you can do so with the settingsJob.enabled value. You can also adjust the CronJob schedule (when it will reset the application settings) with the settingsJob.schedule value.

Configuring Bot Accounts

uds-gitlab-config chart:

  • botAccounts.enabled - set this to true to enable bot accounts.
  • botAccounts.accounts - set this to a list of bot accounts to create. If specified, each account will be created in GitLab with the given username and scopes. A GitLab Personal Access Token (PAT) will be created for the account and stored in the secret specified by secret.name, secret.namespace, and secret.keyName. Any namespaces specified in botAccounts secrets will be created automatically.

Example:

  - username: renovatebot
    scopes:
      - api
      - read_repository
      - write_repository
    secret:
      name: gitlab-renovate
      namespace: renovate
      keyName: TOKEN

This will configure a bot account named renovatebot and create a PAT with scopes api, read_repository, and write_repository for the account. The value of the PAT will be stored in the key TOKEN in a secret gitlab-renovate in the renovate namespace.

Note

If the GitLab instance is configured with a license for Premium or Ultimate, Gitlab Service Accounts will be created. Otherwise, standard user accounts will be created.