From 3ec90445035d1c18f4f06a891861c2a95c6a0af8 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Fri, 14 Jun 2024 12:56:02 -0600 Subject: [PATCH] chore: document how to use the database (#149) ## Description This adds a configuration.md for GitLab ## Related Issue Relates to #124 ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [X] Other (security config, docs update, etc) ## Checklist before merging - [X] Test, docs, adr added or updated as needed - [X] [Contributor Guide Steps](https://github.com/defenseunicorns/uds-package-gitlab/blob/main/CONTRIBUTING.md#developer-workflow) followed --- docs/configuration.md | 43 ++++++++++++++++++++++++ docs/networking.md | 78 ------------------------------------------- 2 files changed, 43 insertions(+), 78 deletions(-) create mode 100644 docs/configuration.md delete mode 100644 docs/networking.md diff --git a/docs/configuration.md b/docs/configuration.md new file mode 100644 index 00000000..329bcd96 --- /dev/null +++ b/docs/configuration.md @@ -0,0 +1,43 @@ +# Configuration + +GitLab in this package is configured through the upstream [GitLab chart](https://docs.gitlab.com/charts/) as well as a UDS configuration chart that supports the following: + +## Networking + +Network policies are controlled via the `uds-gitlab-config` chart in accordance with the [common patterns for networking within UDS Software Factory](https://github.com/defenseunicorns/uds-software-factory/blob/main/docs/networking.md). 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) + +## Database + +GitLab uses Postgres as its backing database service and supports the [common database providers within UDS Software Factory](https://github.com/defenseunicorns/uds-software-factory/blob/main/docs/database.md). + +### 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` setting is 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 (i.e. `gitlab.gitlab.pg-cluster.credentials.postgresql.acid.zalan.do`) +- `global.psql.host` - provides the endpoint to use to connect to the database (i.e. `pg-cluster.postgres.svc.cluster.local`) + +### 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: + +https://github.com/defenseunicorns/uds-software-factory/issues/45 diff --git a/docs/networking.md b/docs/networking.md deleted file mode 100644 index c02f498f..00000000 --- a/docs/networking.md +++ /dev/null @@ -1,78 +0,0 @@ -# Networking - -GitLab is configured by default to assume the internal dependencies that are used for testing (see minio, redis and postgres in the [bundle](bundle/uds-bundle.yaml)). Intentionally, permissive network policies are not created as a default. For example, there is not a default setup of egress anywhere for pods that may need to connect to external storage. - -> [!IMPORTANT] -> If you are using different internal services, cloud services or a mix you will have to configure values in the config chart accordingly via bundle overrides. A couple of example are provided below: - -Configure GitLab for all external services: - -```yaml -# charts/config/values.yaml -storage: - internal: false -redis: - internal: false -postgres: - internal: false -``` - -Configure GitLab for external postgres and s3, but in-cluster redis that is not the dev-redis currently used for testing: - -```yaml -# charts/config/values.yaml -storage: - internal: false -postgres: - internal: false -redis: - internal: true - selector: - app.kubernetes.io/name: redis - namespace: redis - port: 6379 -``` - -Configure GitLab for all external services and a non-default GitLab runner: - -```yaml -# charts/config/values.yaml -storage: - internal: false -postgres: - internal: false -redis: - internal: false - internal: true - selector: - app: gitlab-runner - namespace: my-other-gitlab-runner -``` - -> [!TIP] -> There may be a need to integrate with other in-cluster services that are not a part of the standard connectivity needed by GitLab (for example a Jira integration). As such, there is the ability to add custom rules to allow additional internal network connectivity. - -Add custom rule: - -```yaml -# charts/config/values.yaml -custom: - # Notice no `remoteGenerated` field here on custom internal rule - - direction: Ingress - selector: - app: webservice - remoteNamespace: jira - remoteSelector: - app: jira - port: 8180 - description: "Ingress from Jira" - # No `remoteNamespace`, `remoteSelector`, or `port` fields on rule to `remoteGenerated` - - direction: Egress - selector: - app: webservice - remoteGenerated: Anywhere - description: "Egress from Webservice" -``` - -> [!NOTE] -> The above is just an example of what can be done with the custom key and not representative what any specific integration would need to look like.