Skip to content

feat: add support for Redis Sentinel passwords

Stan Hu requested to merge sh-support-sentinel-password-try2 into master

What does this MR do?

This merge request introduces global.redis.sentinelAuth that will allow admins to create a Redis Sentinel password for all Sentinel instances. redisYmlOverride and instance-specific configuration cannot be used at the moment to reduce the complexity of testing and managing secrets.

GitLab Exporter

  • This uses sentinel_password in the YAML config file.

GitLab Rails

  • Workhorse: SentinelPassword in the config TOML
  • GitLab Rails: sentinel_password in the various Redis YML files

KAS

  • KAS reads the Redis Sentinel secret directly via the sentinel_password_file.

MailRoom

sentinel_username and sentinel_password can be specified as config parameters in gitlab-mail_room v0.0.25 (gitlab-org/ruby/gems/gitlab-mail_room!68 (merged)). The old way of passing the username and password involves adding a username and password field to each host sentinels. This requires gitlab-org/build/CNG!1847 (merged).

Related issues

Relates to #2902 (closed)

Follow-up items

Testing

I created a separate Redis and Redis Sentinel deployment:

redis-deployment.yaml 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:latest
        ports:
        - containerPort: 6379
        env:
        - name: REDIS_PASSWORD
          value: "<password from gitlab-redis-secret secret>"
        command:
        - sh
        - -c
        - |
          echo "user default on >${REDIS_PASSWORD} ~* +@all allchannels" > /tmp/redis.conf
          redis-server /tmp/redis.conf
---
apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    app: redis

sentinel-deployment.yaml 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-sentinel
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis-sentinel
  template:
    metadata:
      labels:
        app: redis-sentinel
    spec:
      containers:
      - name: redis-sentinel
        image: bitnami/redis-sentinel:latest
        ports:
        - containerPort: 26379
        env:
        - name: REDIS_PASSWORD
          value: "<password from gitlab-redis-secret secret>"
        - name: SENTINEL_PASSWORD
          value: "my-sentinel-password"
        command:
        - sh
        - -c
        - |
          echo "Starting Redis Sentinel..."
          cat <<EOF > /opt/bitnami/redis-sentinel/etc/sentinel.conf
          sentinel monitor mymaster redis.default.svc.cluster.local 6379 2
          sentinel auth-pass mymaster ${REDIS_PASSWORD}
          sentinel resolve-hostnames yes
          requirepass ${SENTINEL_PASSWORD}
          EOF
          redis-sentinel /opt/bitnami/redis-sentinel/etc/sentinel.conf
---
apiVersion: v1
kind: Service
metadata:
  name: redis-sentinel
spec:
  ports:
  - port: 26379
    targetPort: 26379
  selector:
    app: redis-sentinel

Then I ran:

kubectl apply -f redis-deployment.yaml
kubectl apply -f sentinel-deployment.yaml

In values.yaml, I updated this:

gitlab:
  mailroom:
    image:
      pullPolicy: Always
      tag: sh-update-mailroom
global:
  redis:
    auth:
      enabled: true
      # secret:
      # key:
    host: mymaster
    # port: 6379
    # user: webservice
    sentinels:
      - host: 'redis-sentinel.default.svc.cluster.local'
        port: 26379
    sentinelAuth:
      enabled: true
      secret: gitlab-redis-sentinel-secret
      key: password

Then I created a secret:

kubectl create secret generic gitlab-redis-sentinel-secret --from-literal=password=my-sentinel-password

Then I deployed GitLab with MailRoom enabled and verified all the pods came up.

Author checklist

For general guidance, please follow our Contributing guide.

Required

For anything in this list which will not be completed, please provide a reason in the MR discussion.

  • Merge Request Title and Description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • MR has a green pipeline.
  • Documentation created/updated.
  • Tests added/updated, and test plan for scenarios not covered by automated tests.
  • Equivalent MR/issue for omnibus-gitlab opened.

Reviewers checklist

Edited by Stan Hu

Merge request reports