Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding support for service account impersonation and short lived tokens #246

Merged
merged 5 commits into from
Jul 30, 2019
Merged

Conversation

rjerrems
Copy link
Contributor

Hi Guys,

Here is a first cut at adding support for short lived tokens / service account impersonation to address this issue:

#243

I have refactored the service account deletion script (renamed to modify-service-account.sh) and updated the preconditions checking script.

Before merge I will need to work on getting tests to pass but was having some trouble getting the full test suite to run locally.

Thanks

@@ -169,6 +170,18 @@ resource "google_project_services" "project_services_authority" {
depends_on = [google_project.main]
}

resource "google_project_service" "iam_credentials_api" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of a separate service block, we should inject this into the activate_apis. (In particular, this would break in the case of authoritatively setting the project services.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been fixed in the latest commit and is injected in the locals block.

/************************************************************************************
Default compute service account action. Options are keep, depriviledge, delete.
***********************************************************************************/
resource "null_resource" "modify_default_compute_service_account" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renaming the resource is likely to lead to some issues with existing projects (causing state migrations). I'd prefer if we kept these as two separate null_resources.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool make sense, this has been fixed in the latest commit.

]
}

/******************************************
Default Service Account configuration
*****************************************/
resource "google_service_account" "default_service_account" {
account_id = "project-service-account"
account_id = "project-service-account"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure to run the format/linting commands.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem, this formatting change was the result of running terraform fmt FYI, running make -s has a bunch of errors locally for me for files I haven't touched, perhaps I am using a different version of shellcheck. Mine is 0.4.7, here is a sample of the errors:

In ./helpers/setup-sa.sh line 171:
\ \ - serviceAccount:${SA_ID}\\
^-- SC1117: Backslash is literal in "\ ". Prefer explicit escaping: "\\ ".
  ^-- SC1117: Backslash is literal in "\ ". Prefer explicit escaping: "\\ ".


In ./helpers/setup-sa.sh line 172:
\ \ role: roles/billing.user" policy-tmp-$$.yml && rm policy-tmp-$$.yml.bak
^-- SC1117: Backslash is literal in "\ ". Prefer explicit escaping: "\\ ".
  ^-- SC1117: Backslash is literal in "\ ". Prefer explicit escaping: "\\ ".

modules/core_project_factory/variables.tf Show resolved Hide resolved
@rjerrems
Copy link
Contributor Author

I have run through the integration tests three times from the last commit and it looks like it is working most of the time, although I have seen this error once (and a couple times on previous commit)

       Error: Invalid count argument
       
         on ../../../modules/core_project_factory/main.tf line 113, in resource "null_resource" "check_if_shared_vpc_subnets_contains_items_with_invalid_name":
        113:   count = length(
        114:     compact(null_resource.shared_vpc_subnet_invalid_name.*.triggers.name),
        115:   ) == 0 ? 0 : 1
       
       The "count" value depends on resource attributes that cannot be determined
       until apply, so Terraform cannot predict how many instances will be created.
       To work around this, use the -target argument to first apply only the
       resources that the count depends on.

Is this a known issue or something I may have introduced?

@aaron-lane aaron-lane added the enhancement New feature or request label Jul 22, 2019
@aaron-lane aaron-lane requested a review from morgante July 22, 2019 21:28
@aaron-lane
Copy link
Contributor

@rjerrems that issue is a regression which exists on the master branch so it's not caused by your changes.

@rjerrems
Copy link
Contributor Author

Ok cool - good to know. Thanks @aaron-lane

@rjerrems
Copy link
Contributor Author

Hi Guys, Just giving this a nudge - let me know if there is anything that needs to be worked on for this?

@morgante morgante merged commit a48da23 into terraform-google-modules:master Jul 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants