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

Add role arn #5619

Merged
merged 4 commits into from
Jan 21, 2022
Merged

Add role arn #5619

merged 4 commits into from
Jan 21, 2022

Conversation

Jseph
Copy link
Contributor

@Jseph Jseph commented Jan 14, 2022

Adds the option to use role_arn for the transfer service resource. Fixes hashicorp/terraform-provider-google#10880.

If this PR is for Terraform, I acknowledge that I have:

  • Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
  • Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.

I did generate this and make sure it could build. make test and make lint didn't do anything because there was no rule for the make target.

  • Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).

Looks like S3 sources aren't supported in the third party tests. Probably because it would require infrastructure to create resources in AWS S3?

  • Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).

There aren't any relevant tests as far as I know.

Release Note Template for Downstream PRs (will be copied)

storage: added field `transfer_spec.aws_s3_data_source.role_arn` to `google_storage_transfer_job`

@modular-magician
Copy link
Collaborator

Hello! I am a robot who works on Magic Modules PRs.

I have detected that you are a community contributor, so your PR will be assigned to someone with a commit-bit on this repo for initial review.

Thanks for your contribution! A human will be with you soon.

@slevenick, please review this PR or find an appropriate assignee.

Copy link
Contributor

@slevenick slevenick left a comment

Choose a reason for hiding this comment

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

Can you add a test that uses the new field?

@@ -349,7 +349,7 @@ func awsS3DataSchema() *schema.Resource {
},
"aws_access_key": {
Type: schema.TypeList,
Required: true,
Optional: true,
Copy link
Contributor

Choose a reason for hiding this comment

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

Now that we are moving this from Required -> Optional can we add an AtLeastOneOf with aws_access_key & role_arn so that one of them must be specified?

We try to avoid allowing empty blocks in configs as they tend to cause problems

Copy link
Member

Choose a reason for hiding this comment

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

+1 , either of those is required, won't work with neither

Copy link
Contributor

Choose a reason for hiding this comment

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

Does it work with both set? If not, we can use ExactlyOneOf instead

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Technically the backend allows you to set both but

  • There's no reason to do so
  • aws_access_key is never returned by the service
  • If role_arn is set it takes priority

so I think it's fine to wrap this in ExactlyOneOf even though the underlying proto couldn't wrap these fields in a OneOf to maintain backwards compatibility.

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 3 files changed, 33 insertions(+), 22 deletions(-))
Terraform Beta: Diff ( 2 files changed, 15 insertions(+), 4 deletions(-))

@Jseph
Copy link
Contributor Author

Jseph commented Jan 14, 2022

Sorry I'm having trouble with figuring out what to do for testing. There aren't currently any tests that use AwsS3Data and I'm not really sure how to add one. Do these tests actually end up creating real transfer jobs or are they just testing the parsing/serialization logic?

@Jseph
Copy link
Contributor Author

Jseph commented Jan 14, 2022

Specifically this code causes me concern

resource "google_storage_bucket_iam_member" "data_sink" {
  bucket = google_storage_bucket.data_sink.name
  role   = "roles/storage.admin"
  member = "serviceAccount:${data.google_storage_transfer_project_service_account.default.email}"
}

It looks like it's creating a real GCS bucket. I don't think there's any way to do that for an AWS S3 bucket so I don't know how to write a test for this.

@slevenick
Copy link
Contributor

Specifically this code causes me concern

resource "google_storage_bucket_iam_member" "data_sink" {
  bucket = google_storage_bucket.data_sink.name
  role   = "roles/storage.admin"
  member = "serviceAccount:${data.google_storage_transfer_project_service_account.default.email}"
}

It looks like it's creating a real GCS bucket. I don't think there's any way to do that for an AWS S3 bucket so I don't know how to write a test for this.

These tests do create real resources when run. Can we set some arbitrary string as the role_arn, or does the API enforce that the AWS resource actually exists?

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 2 files changed, 22 insertions(+), 5 deletions(-))
Terraform Beta: Diff ( 3 files changed, 44 insertions(+), 27 deletions(-))

@Jseph
Copy link
Contributor Author

Jseph commented Jan 14, 2022

These tests do create real resources when run. Can we set some arbitrary string as the role_arn, or does the API enforce that the AWS resource actually exists?

Yes the API actually checks that the source bucket exists and that the provided credentials are sufficient to access it. If a fake string is sent we'll get back a 4xx error.

@slevenick
Copy link
Contributor

These tests do create real resources when run. Can we set some arbitrary string as the role_arn, or does the API enforce that the AWS resource actually exists?

Yes the API actually checks that the source bucket exists and that the provided credentials are sufficient to access it. If a fake string is sent we'll get back a 4xx error.

Ok that's tricky then, we won't have valid AWS credentials in the CI runner. Can you set up the correct resources yourself and test that this field works correctly in a real environment?

@Jseph
Copy link
Contributor Author

Jseph commented Jan 14, 2022

These tests do create real resources when run. Can we set some arbitrary string as the role_arn, or does the API enforce that the AWS resource actually exists?

Yes the API actually checks that the source bucket exists and that the provided credentials are sufficient to access it. If a fake string is sent we'll get back a 4xx error.

Ok that's tricky then, we won't have valid AWS credentials in the CI runner. Can you set up the correct resources yourself and test that this field works correctly in a real environment?

Ok I've got someone with more terraform experience to help out on Tuesday. I'll update with the results thanks!

@lanre-OG
Copy link

Carried out the below test with the compiled local provider:

  1. Create an STS resource with the role_arn parameter only : Successful

  2. Create an STS resource with the aws_access_key parameter only: Successful

  3. Create an STS resource with both aws_access_key and role_arn parameter specified: Error

    │ Error: Invalid combination of arguments
    │ with google_storage_transfer_job.test-backup,
    │ on main.tf line 92, in resource "google_storage_transfer_job" "test-backup":
    │ 92: role_arn = var.role_arn
    │ "transfer_spec.0.aws_s3_data_source.0.role_arn": only one of
    transfer_spec.0.aws_s3_data_source.0.aws_access_key,transfer_spec.0.aws_s3_data_source.0.role_arn can be specified,
    │ but transfer_spec.0.aws_s3_data_source.0.aws_access_key,transfer_spec.0.aws_s3_data_source.0.role_arn were specified.

  4. Create an STS resource with neither aws_access_key and role_arn parameter specified: Error

    │ Error: Invalid combination of arguments
    │ with google_storage_transfer_job.test-backup,
    │ on main.tf line 85, in resource "google_storage_transfer_job" "test-backup":
    │ 85: aws_s3_data_source {
    │ "transfer_spec.0.aws_s3_data_source.0.role_arn": one of
    transfer_spec.0.aws_s3_data_source.0.aws_access_key,transfer_spec.0.aws_s3_data_source.0.role_arn must be specified

@slevenick slevenick self-requested a review January 20, 2022 18:58
@slevenick
Copy link
Contributor

/gcbrun

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 2 files changed, 22 insertions(+), 5 deletions(-))
Terraform Beta: Diff ( 2 files changed, 22 insertions(+), 5 deletions(-))

@modular-magician
Copy link
Collaborator

I have triggered VCR tests in RECORDING mode for the following tests that failed during VCR: TestAccDatasourceGoogleServiceNetworkingPeeredDnsDomain_basic|TestAccApigeeEnvironmentIamMemberGenerated|TestAccCloudbuildWorkerPool_basic|TestAccContainerNodePool_withInvalidUpgradeSettings|TestAccServiceNetworkingPeeredDNSDomain_basic You can view the result here: https://ci-oss.hashicorp.engineering/viewQueued.html?itemId=246233

Copy link
Contributor

@slevenick slevenick left a comment

Choose a reason for hiding this comment

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

Looks good to me! Thanks for handling the testing

@slevenick slevenick merged commit 6f986f1 into GoogleCloudPlatform:master Jan 21, 2022
@Jseph Jseph deleted the AddRoleArn branch January 21, 2022 19:07
lcaggio pushed a commit to lcaggio/magic-modules that referenced this pull request Mar 16, 2022
* Adds support for role_arn for storage_transfer_job

* Fix syntax error

* Fix build error.

* Adds ExactlyOneOf check.

Co-authored-by: Joseph Cox <[email protected]>
lcaggio pushed a commit to lcaggio/magic-modules that referenced this pull request Mar 17, 2022
* Adds support for role_arn for storage_transfer_job

* Fix syntax error

* Fix build error.

* Adds ExactlyOneOf check.

Co-authored-by: Joseph Cox <[email protected]>
lcaggio pushed a commit to lcaggio/magic-modules that referenced this pull request Mar 18, 2022
* Adds support for role_arn for storage_transfer_job

* Fix syntax error

* Fix build error.

* Adds ExactlyOneOf check.

Co-authored-by: Joseph Cox <[email protected]>
betsy-lichtenberg pushed a commit to betsy-lichtenberg/magic-modules that referenced this pull request Apr 25, 2022
* Adds support for role_arn for storage_transfer_job

* Fix syntax error

* Fix build error.

* Adds ExactlyOneOf check.

Co-authored-by: Joseph Cox <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add google_storage_transfer_job support for AWS RoleArn for temporary credentials
5 participants