chore(tf): create password for read-only SQL user on staging

[AndrewKostka]

Process for creating a new observer user:

echo $(kubectl get secret --namespace default sql-secrets-init-passwords -o jsonpath="{.data.SQL_INIT_OBSERVER}" | base64 --decode)
kubectl exec -it sql-mariadb-primary-0 -- /bin/bash -c 'mysql -u root -p${MARIADB_ROOT_PASSWORD}'

CREATE USER IF NOT EXISTS 'observer'@'%' IDENTIFIED BY 'TODO_PASSWORD_FROM_ECHO';
GRANT SELECT, SHOW VIEW ON apidb.* TO 'observer'@'%';
GRANT SELECT, SHOW VIEW ON `mwdb_%`.* TO 'observer'@'%';
GRANT SELECT, SHOW VIEW ON `mediawiki`.* TO 'observer'@'%';
FLUSH PRIVILEGES;

[tarrow]

This looks good to me schematically. I have at least a small worry that the new method we're now using for working through modules might have a side effect of us rotating the other secrets that we don't want to touch

My "plan" of this PR looks like:

  # random_password.sql-passwords["staging-observer"] will be created
  + resource "random_password" "sql-passwords" {
      + bcrypt_hash      = (sensitive value)
      + id               = (known after apply)
      + keepers          = {
          + "rotate" = "2"
        }
      + length           = 32
      + lower            = true
      + min_lower        = 0
      + min_numeric      = 0
      + min_special      = 0
      + min_upper        = 0
      + number           = true
      + numeric          = true
      + override_special = "_%@"
      + result           = (sensitive value)
      + special          = true
      + upper            = true
    }

  # module.wbaas2-k8s-secrets.kubernetes_secret.sql-secrets-init-passwords["adhoc-jobs"] will be updated in-place
  ~ resource "kubernetes_secret" "sql-secrets-init-passwords" {
      ~ binary_data = (sensitive value)
        id          = "adhoc-jobs/sql-secrets-init-passwords"
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # module.wbaas2-k8s-secrets.kubernetes_secret.sql-secrets-init-passwords["api-jobs"] will be updated in-place
  ~ resource "kubernetes_secret" "sql-secrets-init-passwords" {
      ~ binary_data = (sensitive value)
        id          = "api-jobs/sql-secrets-init-passwords"
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # module.wbaas2-k8s-secrets.kubernetes_secret.sql-secrets-init-passwords["default"] will be updated in-place
  ~ resource "kubernetes_secret" "sql-secrets-init-passwords" {
      ~ binary_data = (sensitive value)
        id          = "default/sql-secrets-init-passwords"
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 1 to add, 3 to change, 0 to destroy.

Did you already try this locally and confirm this "change" is actually a noop rather than regenerating the passwords?

[AndrewKostka]

I didn't see any existing credentials being rotated when I applied this change in my local environment. However, it would be good if you could double-check this in your environment as well. Judging by the plan outputs, it should work the same way on staging, but I can't say that for certain due to the added secrets module step for staging.

I checked before and after applying the changes using:

kubectl get secret --namespace default sql-secrets-init-passwords -o yaml

This is what my plan looked like:

  # kubernetes_secret.sql-secrets-init-passwords["adhoc-jobs"] will be updated in-place
  ~ resource "kubernetes_secret" "sql-secrets-init-passwords" {
      ~ binary_data                    = (sensitive value)
        id                             = "adhoc-jobs/sql-secrets-init-passwords"
        # (4 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # kubernetes_secret.sql-secrets-init-passwords["api-jobs"] will be updated in-place
  ~ resource "kubernetes_secret" "sql-secrets-init-passwords" {
      ~ binary_data                    = (sensitive value)
        id                             = "api-jobs/sql-secrets-init-passwords"
        # (4 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # kubernetes_secret.sql-secrets-init-passwords["default"] will be updated in-place
  ~ resource "kubernetes_secret" "sql-secrets-init-passwords" {
      ~ binary_data                    = (sensitive value)
        id                             = "default/sql-secrets-init-passwords"
        # (4 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # random_password.sql-passwords["observer"] will be created
  + resource "random_password" "sql-passwords" {
      + bcrypt_hash      = (sensitive value)
      + id               = (known after apply)
      + length           = 32
      + lower            = true
      + min_lower        = 0
      + min_numeric      = 0
      + min_special      = 0
      + min_upper        = 0
      + number           = true
      + numeric          = true
      + override_special = "_%@"
      + result           = (sensitive value)
      + special          = true
      + upper            = true
    }

Plan: 1 to add, 3 to change, 0 to destroy.

[tarrow]

Tested it locally for me and the "binary blob change" is just the new observer being added