Ability to prefix session cookies

What does this MR do?

As part of the Cells project, we need to have the option to prefix session cookies values by a prefix, to enable us to generate cookies with a prefixed value for each cell. See https://docs.gitlab.com/ee/architecture/blueprints/cells/http_routing_service.html#routing-rules for more information.

As part of this MR we added the ability to configure GitLab app itself to change the prefix. In this MR, we are adding this option to the Helm Charts.

Related issues

Addressing: gitlab-org/gitlab#439945 (closed)

Related MRs

• For OmniBus: gitlab-org/omnibus-gitlab!7605 (merged)

Verifying the changes

Requirements

1. You need a machine with Kubernetes and Helm installed. To test the changes using MiniKube for example, see this page: https://docs.gitlab.com/charts/development/minikube/

Steps

1. Pull this repository and checkout this MR branch 439945-ability-to-prefix-session-cookies. git checkout --track origin/439945-ability-to-prefix-session-cookies
2. Run helm dependency update
3. Deploy GitLab using helm with some custom prefix value (you can also test the default value ""):

helm upgrade --install gitlab . --timeout=900s -f examples/values-minikube.yaml --set prometheus.install=false --set gitlab-runner.install=false --set=global.grafana.enabled=false --set global.rails.session_store.session_cookie_token_prefix=custom_token_

4. Locate a webservice pod using kubectl get pods
5. kubectl exec -ti WEBSERVICE-POD -- bash
6. cd /srv/gitlab
7. ./bin/rails c
8. Inspect Rails.application.config.session_options
9. You should see something like

{:redis_server=>
  {:host=>"gitlab-redis-master.default.svc",
   :port=>6379,
   :password=>"*********************",
   :id=>nil,
   :command_builder=>Gitlab::Redis::CommandBuilder,
   :custom=>{:instrumentation_class=>"Sessions"},
   :namespace=>"session:gitlab"},
 :key=>"_gitlab_session",
 :secure=>true,
 :httponly=>true,
 :expires_in=>604800,
 :path=>"/",
 :session_cookie_token_prefix=>"custom_token_"}

Author checklist

See Definition of done.

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

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• When ready for review, follow the instructions in the "Reviewer Roulette" section of the Danger Bot MR comment, as per the Distribution experimental MR workflow

For merge requests from forks, consider the following options for Danger to work properly:

• Consider using our community forks instead of forking your own project. These community forks have the GitLab API token preconfigured.
• Alternatively, see our documentation on configuring Danger for personal forks.

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added/updated
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened. Here -> gitlab-org/omnibus-gitlab!7605 (merged)
• Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes)
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.