-
Notifications
You must be signed in to change notification settings - Fork 982
Document the need to add pubsub roles to the read-only SA in bootstrap in specific use cases #2540
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
Comments
Add these two roles to the bootstrap 0r service account solves the bootstrap plan phase issue. Similar permission issues may affect resman plan phase as well, will report if found. roles/pubsub.admin in organization-iam.tf file. |
Thanks for investigating the fix. Can you send a PR? |
Wouldn't giving admin rights to the 0r service accounts be a risk? I have had other similar issues with the plan related service accounts and ended up creating separate custom role along the lines of
|
Yes, the plan is absolutely to add a custom role. Was mentioning this in a direct chat, sorry for not circling back here to say the same and good catch :) |
Gave this some thoughts, and I'm not convinced we should add a role for pubsub by default: FAST comes preconfigured with log sinks using log buckets as destinations, so the role is not needed by default; and granting it at the organization level might be undesired for some (or many) customers. In general, FAST's expectation is that sinks requiring pubsub are generally used to pipe security-related records to onprem SIEMs, and those are best handled in a security-specific stage. Sinks in the bootstrap stage are mainly concerned with making some critical organization-level data easily consumable for operations, and for that use case log buckets are a good choice. What we should do instead is making this explicit in the stage's README, so the relevant role can be added via the local tfvars file when in cases where handling pubsub sink destination in a separate stage is not desired or requires too much effort. As for storage permissions, the read-only plan is run without a lockfile on purpose so those are not needed. |
Describe the bug
When logSink is defined, running FAST CICD with Git Action failed at the plan phase, reporting error about could not check IAM policy about the Pub/Sub topics. Permission 'pubsub.topics.getIamPolicy' requires pubsub.admin role, a simple viewer role does not have access.
It also reported that cannot remove the lock on TF state file due to 'storage.objects.delete' permission missing. The predefined role 'storage.objectUser' role has that permission.
Environment
To Reproduce
Follow the CICD steps in 0-bootstrap phase, stage bootstrap in a Github repo and set up Git Action.
Create a PR, which triggers a plan build, and build will fail with the errors.
An alternative way to check is to run the following command with an account that can impersonate into the 0r service account to validate the permission issue:
Expected behavior
Git Action should complete the plan cleanly without error.
Result
Additional context
Add any other context about the problem here
The text was updated successfully, but these errors were encountered: