Page MenuHomeDevCentral

Figure how to deploy automatically /var/51-wwwroot credentials
Closed, ResolvedPublic

Description

To clone Git repositories, we need a key, but when provisioning a new server, if we generate a new key, it won't be available on Git repositories hosting like GitHub.

So, currently, deployment fails like this:

----------
          ID: /var/51-wwwroot/api
    Function: git.latest
        Name: ssh://vcs@devcentral.nasqueron.org:5022/source/api.git
      Result: False
     Comment: Failed to check remote refs: Host key verification failed.
              fatal: Could not read from remote repository.

              Please make sure you have the correct access rights
              and the repository exists.
     Started: 13:25:53.395911
    Duration: 113.33 ms
     Changes:

Perhaps a master key would be more pertinent, if so, that's a candidate for Vault.

Event Timeline

dereckson triaged this task as High priority.Dec 16 2019, 14:08
dereckson created this task.
dereckson updated the task description. (Show Details)

Perhaps a master key would be more pertinent, if so, that's a candidate for Vault.

We've a deploy key in salt master, let's use it.

But what if a server doesn't have the saltmaster role? T1569 will take care of that.

D2151 works well, but there are two issues:

  • a conflict between devserver and saas-mediawiki roles -> /var/51-wwwroot/saas-mediawiki Comment: Group mediawiki is not available
  • /var/51-wwwroot/tools/includes/mediawikibot.php: File not found, but that exhibits a symlink issue (filed as T1575)

It seems it's also possible to store the deploy key on the master, as long as it's fine to copy it to the server:

salt/states/git.py
for ident_path in identity:
    if 'salt://' in ident_path:

That means this key should match a read-only access.

Documentation says Zemke-Rhyme Phabricator account should be used.

Now we've Vault, yes, the key could be stored in Vault instead to be regenerated.

The role webserver-alkane instead of the role webserver-legacy can be deployed to WindRiver.

With Alkane, we can then use the recipes scripts to clone, then edit the remote to switch from https to ssh perhaps?

Okay, let's do an easy thing to solve that for DevCentral repositories:

  • A SSH key has been created for @alken-orin account
  • The key is stored in Vault under ops/secrets/nasqueron/deploy/deploy_keys/alken-orin path
  • Salt can provision it on devserver
  • We use explicitly the path to that key to clone those repositories

As an alternative for GitHub repositories, we can use the same strategy:

  • A read-only deploy key per repository
    • Vault: ops/secrets/nasqueron/deploy/deploy_keys/by_repo/github/<org or user>/<repo>
    • GitHub: in your repository settings under Deploy keys, write the public key
  • A bot account per organization
    • Vault: ops/secrets/nasqueron/deploy/deploy_keys/by_account/github/<org>/<repo>
    • GitHub: in your bot account regular SSH keys, write the public key

For BitBucket, deploy key strategy, under ops/secrets/nasqueron/deploy/deploy_keys/by_repo/bitbucket/<org or user>/<repo>

No known repository under GitLab currently.