search

Swirrl / datahost-prototypes

Eclipse Public License 1.0
0 stars 0 forks source link

Manage basic auth as google secret #214

Closed andrewmcveigh closed 1 year ago

andrewmcveigh commented 1 year ago

Use google secrets as a method to manage the basic auth secret.

NOTE: Before merge/deploy, we need to test the running instance & container's access to secret manage.

Method

Use the google secrets API directly in application code, using the gcloud java library.

Benefits

Can run same code locally as in prod. Doesn't leave env vars or config with secrets lying around. Recommended by Google.

Downsides

App has a startup dependency on google secrets API. Though any other method that does not supply the secret to the compiled artifact, loading the secret at runtime, has the same dependency.

Adds complexity to the dev environment to run this code (it doesn't run in dev/test usually). The user's environment must have gcloud credentials setup, and the user must have access to the secretmanager.

Running

The system running this code needs access to the secretmanager.secretAccessor role, including a developer's environment if they want to test it.

Access is granted to the LDAPI instance's service account via the terraform change, output below:

Terraform changes

Terraform will perform the following actions:

  # module.dev.module.server.google_project_iam_member.ldapi_service_account_permissions will be destroyed
  # (because resource uses count or for_each)
  - resource "google_project_iam_member" "ldapi_service_account_permissions" {
      - etag    = "BwYDbrnz8Io=" -> null
      - id      = "swirrl-devops-infrastructure-1/roles/artifactregistry.reader/serviceAccount:dev-ldapi-account@swirrl-ons-datahost.iam.gserviceaccount.com" -> null
      - member  = "serviceAccount:dev-ldapi-account@swirrl-ons-datahost.iam.gserviceaccount.com" -> null
      - project = "swirrl-devops-infrastructure-1" -> null
      - role    = "roles/artifactregistry.reader" -> null
    }

  # module.dev.module.server.google_project_iam_member.ldapi_service_account_permissions["roles/artifactregistry.reader"] will be created
  + resource "google_project_iam_member" "ldapi_service_account_permissions" {
      + etag    = (known after apply)
      + id      = (known after apply)
      + member  = "serviceAccount:dev-ldapi-account@swirrl-ons-datahost.iam.gserviceaccount.com"
      + project = "swirrl-devops-infrastructure-1"
      + role    = "roles/artifactregistry.reader"
    }

  # module.dev.module.server.google_project_iam_member.ldapi_service_account_permissions["roles/secretmanager.secretAccessor"] will be created
  + resource "google_project_iam_member" "ldapi_service_account_permissions" {
      + etag    = (known after apply)
      + id      = (known after apply)
      + member  = "serviceAccount:dev-ldapi-account@swirrl-ons-datahost.iam.gserviceaccount.com"
      + project = "swirrl-devops-infrastructure-1"
      + role    = "roles/secretmanager.secretAccessor"
    }

Plan: 2 to add, 0 to change, 1 to destroy.
andrewmcveigh commented 1 year ago

I've checked that the service account has the right permissions (inside a running container, on the instance) to access the secret.

As far as I can tell, the ldapi container does have access to the service account creds, which have access to the secret, and the container can start up on the instance. So I think it's ready to merge.