feat: add alternative (Github and Gitlab) to Cloud Build Deployment with CSR #1329
Conversation
|
We'll prob need a release on https://github.com/terraform-google-modules/terraform-google-bootstrap to reference the modules with terraform registry |
caetano-colin
changed the title
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
…lin/terraform-example-foundation into add-cloudbuild-github-support
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
1 similar comment
|
/gcbrun |
|
/gcbrun |
5 similar comments
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
2 similar comments
|
/gcbrun |
|
/gcbrun |
|
/gcbrun |
caetano-colin
requested review from
rjerrems,
gtsorbo,
eeaton,
sleighton2022 and
a team
as code owners
| }) | ||
| github_pat = null | ||
| github_app_id = null | ||
| gitlab_read_authorizer_credential = null |
There was a problem hiding this comment.
It's not clear to me, why are the credentials set in locals here?
Other tf files that reference this use var.cloudbuildv2_repository_config
There was a problem hiding this comment.
this is being used on modules/infra_pipelines input.
the value is used to replicate the same behavior as today (CSR with bu1-example-app being created) by default
if the user specified something different than CSR, the local value will not be used:
module "infra_pipelines" {
source = "../../modules/infra_pipelines"
count = local.enable_cloudbuild_deploy ? 1 : 0
org_id = local.org_id
cloudbuild_project_id = module.app_infra_cloudbuild_project[0].project_id
cloud_builder_artifact_repo = local.cloud_builder_artifact_repo
remote_tfstate_bucket = local.projects_remote_bucket_tfstate
billing_account = local.billing_account
default_region = var.default_region
cloudbuildv2_repository_config = local.use_csr ? local.csr_repo_config : var.cloudbuildv2_repository_config
private_worker_pool_id = local.cloud_build_private_worker_pool_id
}
| > Note: Recommended names for the repositories are, in sequence: `gcp-bootstrap`, `gcp-org`, `gcp-environments`, `gcp-networks`, `gcp-projects` and `tf-cloud-builder`; If you choose other names for your repository make sure you update `terraform.tfvars` the repository names under `cloudbuildv2_repository_config` variable. | ||
|
|
||
| - [Install Cloud Build App on Github](https://github.com/apps/google-cloud-build). After the installation, take note of the application id, it will be used in `terraform.tfvars`. | ||
| - [Create Personal Access Token on Github with `repo` and `read:user` (or if app is installed in org use `read:org`)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) - After creating the token, it will be inserted into `terraform.tfvars`. |
There was a problem hiding this comment.
This seems like a good way for somebody's GitHub to get taken over when they publish their token... 😱
I see there are a few additional references that added the secretmanager.googleapis.com API, it would make sense to use that to store the credential securely instead of hardcoding the credential in terraform.tfvars. But it looks the Secret Manager API is enabled, but not actually used to manage these secrets? Or am I missing something?
There was a problem hiding this comment.
The secret manager will be used to create the cloudbuild connection on the module under bootstrap repository (cloudbuild_repo_connection module): https://github.com/terraform-google-modules/terraform-google-bootstrap/blob/master/modules/cloudbuild_repo_connection/main.tf#L37
I discussed with @daniel-cit about how the user will inform the git credentials, here are the options we raised:
- token in
terraform.tfvars, inside a object variable with validation rules, the objective is to ensure the user won't make mistakes when specifying the interface (we developed the solution using this option) - token in
secretmanager- we did not use this because it would require 0-bootstrap to be refactored: the secrets project, and secret version resource must exist prior to the cloudbuild resource provisioning with terraform - token in terraform variable, but specified using env variables, for example:
TF_VAR_github_token- we did not choose to use this because it would require us to give up on the variable validation rules (https://github.com/caetano-colin/terraform-example-foundation/blob/add-cloudbuild-github-support/0-bootstrap/variables.tf#L225), since we would have to remove the token field from the object spec. The same goes for this variable spec on bootstrap repo: https://github.com/terraform-google-modules/terraform-google-bootstrap/blob/master/modules/cloudbuild_repo_connection/variables.tf#L22
|
|
||
| > Note: Recommended names for the repositories are, in sequence: `gcp-bootstrap`, `gcp-org`, `gcp-environments`, `gcp-networks`, `gcp-projects` and `tf-cloud-builder`; If you choose other names for your repository make sure you update `terraform.tfvars` the repository names under `cloudbuildv2_repository_config` variable. | ||
|
|
||
| - An access token with the `api` scope to use for connecting and disconnecting repositories. |
There was a problem hiding this comment.
Same concern as the GitHub credentials on 217
There was a problem hiding this comment.
Hi @eeaton we will need to split 0-bbotstrap step in to a Seed step and CI/CD step so that we can properly use secrets, so that the secrets (google_secret_manager_secret) that need to be used in the CI/CD can be created before usage and the secret version manually created by the use before executing the CI/CD step.
This PR adds two alternatives to Cloud Build deployment with CSR: Gitlab and Github
The user will bring their own repositories through a new variable
cloudbuildv2_repository_config. This is necessary in steps 0-bootstrap for the steps repos and 4-projects to create the appinfra repos.By default, if the user does not define the variable, CSR will be used, the integration test in this build is using CSR