Page MenuHomePhabricator

Requesting SSH keypair for deployment server keyholder to push to Gerrit
Closed, ResolvedPublicRequest

Description

This task is to generate a new ssh key pair, grant access to some groups and arm it in the deployment server keyholder.

Context

When running the MediaWiki train, we run scap deploy-promote which update the MediaWiki versions in wikiversions.json, craft a git commit and send it to Gerrit with a +2.

The push is currently done with our personal account which requires us to store sensible credentials either in:

  • a .netrc file if we push over https
  • a local personal ssh keypair in our home dir on the deployment server

T306425 is to push the git commit with a service user trainbranchbot which is already existing in Gerrit. We would use the keyholder to hold the credentials allowing us to push to Gerrit.

Request

We will use the Gerrit/LDAP user trainbranchbot, I am guessing we can use the same name for the key (/etc/keyholder.d/trainbranchbot).

The key should be allowed to any groups used to deploy MediaWiki, I think we use the mwdeploy Keyholder agent for the MediaWiki deployment which is configured as:

hieradata/role/common/deployment_server/kubernetes.yaml
profile::keyholder::server::agents:
  mwdeploy:
    trusted_groups:
      - wikidev
      - mwdeploy

We can essentially repeat that configuration:

hieradata/role/common/deployment_server/kubernetes.yaml
profile::keyholder::server::agents:
  trainbranchbot:
    trusted_groups:
      - wikidev
      - mwdeploy

The key is exclusively going to be used to reach to Gerrit hence why we are not reusing the mwdeploy name which is a unix user.

Once the key has been generated and keyholder configured and armed, we will need the public key in order to add it to the Gerrit trainbranchbot user preferences.

Name of approving party (manager for WMF/WMDE staff): @thcipriani

Event Timeline

SLyngshede-WMF edited projects, added serviceops; removed SRE-Access-Requests.
SLyngshede-WMF added a subscriber: SLyngshede-WMF.

This doesn't appear to be an SRE-Access-Request. Adding the ServiceOps tags, as they are involved in the Kubernetes migration and it makes sense to loop them in.

dancy added a subscriber: dancy.

Pinging @JMeybohm and @Dzahn for support.

Change 807192 had a related patch set uploaded (by Thcipriani; author: Thcipriani):

[operations/puppet@production] Keyholder: add new agent for trainbranchbot

https://gerrit.wikimedia.org/r/807192

Talked to @LSobanski and he asked for some clarification on the steps we need root help with.

Here are all the steps Release Engineering doesn't have sufficient permissions to do:

  1. generate a new keypair and add it to puppet secrets
    • RelEng needs the public key
  2. Merge: #807192
    • This add a new keyholder::agent in puppet
    • Uses secret("keyholder/trainbranchbot") generated in step one
  3. Trigger a puppet run on deployment hosts
  4. Run SSH_AUTH_SOCK=/run/keyholder/proxy.sock ssh-add -l to ensure keys are added
  5. Restart keyholder-proxy service: sudo systemctl restart keyholder-proxy to ensure new permissions are loaded from /etc/keyholder-auth.d/

I would assume we can reuse the pwstore/pw.git/deployment-key-passphrase for this as the audience is the same as well?

Change 807192 merged by Alexandros Kosiaris:

[operations/puppet@production] Keyholder: add new agent for trainbranchbot

https://gerrit.wikimedia.org/r/807192

I would assume we can reuse the pwstore/pw.git/deployment-key-passphrase for this as the audience is the same as well?

Good assumption! It's actually more like a requisite as having the same passphrase there makes life a bit easier when doing the keyholder arm dance. Instead of specifying N different keys, only 1 is needed.

key generated, change merged, keyholder and keyholder-proxy restart and rearmed. I think we are done on this front! I am gonna resolve by reopen please if anything is amiss.

Thank you @akosiaris !

What's the official way to collect the public key?

Thank you @akosiaris !

What's the official way to collect the public key?

Can't say we have an official way to collect the public key, but this should do:

deploy1002:~$ SSH_AUTH_SOCK=/run/keyholder/proxy.sock ssh-add -L |grep trainbranchbot

Beautiful.

I added the public key to Gerrit's trainbranchbot using the following command:

echo ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIA9PnDpx0+F5mgJUbLxiCOFm2G5anUPaZJvgG9d+XhMk /etc/keyholder.d/trainbranchbot | ssh \
-p29418 gerrit.wikimedia.org gerrit set-account trainbranchbot --add-ssh-key -

Change 808058 had a related patch set uploaded (by Dzahn; author: Dzahn):

[labs/private@master] add missing fake keys for keyholder/trainbranchbot

https://gerrit.wikimedia.org/r/808058

fake secrets were needed to be able to puppet compile scap changes such as https://gerrit.wikimedia.org/r/c/operations/puppet/+/806397

Change 808058 merged by Dzahn:

[labs/private@master] add missing fake keys for keyholder/trainbranchbot

https://gerrit.wikimedia.org/r/808058