Closed SamCloudbakers closed 1 year ago
@SamCloudbakers Thanks for the ticket. We will come up with the related documentation.
Hey @SamCloudbakers - we're currently rewriting the entire GCP collector to bring it on par with the AWS collector. Part of that is having each services exact required permissions as part of the collector code so we can auto-generate the documentation for it, like we do for AWS.
Right now to get you started, the APIs the current collector uses are compute
, sqladmin
, cloudbilling
, container
and cloudresourcemanager
. For resource collection we generally require the get
and list
permissions for all resources available on those APIs. For updating labels the setLabels
and for cleanup the delete
permissions. The last two are optional and only required if you plan on using the tag update/delete
and cleanup
automation functions.
@lloesche and @aquamatthias I really appreciate the quick responses on this! I would consider this great news, as it means GCP support is something this product is targeting long-term.
For now - It looks like I can use the pre-defined ".viewer" Role variants for each of the APIs you have listed above.
Thank you!
@SamCloudbakers
it means GCP support is something this product is targeting long-term.
Yes, 100%. To give you some background. I wrote the current version of the GCP collector at my last job to solve the issues we had there. Mainly automated cleanup of old resources and tag (label) validation/correction. As such the current GCP collector only contains the resources and properties that I required back then.
The new collector however contains all resources and all their properties. If you happen to be somewhat comfortable with Python you can check out https://github.com/someengineering/resoto/tree/main/plugins/gcp/resoto_plugin_gcp/resources to track the progress of the new collector and the resources and properties it already contains.
Interesting, that makes a lot of sense. We've all developed some Python automation to solve bespoke standardization and janitorial problems at one point or another. That's what really drew me to Resoto was the potential to write those sorts of automation jobs in a standardized framework that I could apply to all of the GCP Orgs I touch day to day.
I'll definitely take a look at some of the code, I'm curious to see how all of this works together.
@holopin-bot @SamCloudbakers
Thank you for this issue, and the details on your use case! Love your last comment - "janitorial problems" - precisely one of the reasons why we built Resoto!
Congratulations @SamCloudbakers, you just earned a badge! Here it is: https://holopin.io/claim/clez8e1tp09140gmb2ey69pwo
This badge can only be claimed by you, so make sure that your GitHub account is linked to your Holopin account. You can manage those preferences here: https://holopin.io/account. Or if you're new to Holopin, you can simply sign up with GitHub, which will do the trick!
We are now exporting the required IAM permissions and automatically uploading them to the following URIs in yaml and json format: https://cdn.some.engineering/resoto/gcp/edge/resoto_access.yaml https://cdn.some.engineering/resoto/gcp/edge/resoto_access.json https://cdn.some.engineering/resoto/gcp/edge/resoto_mutate.yaml https://cdn.some.engineering/resoto/gcp/edge/resoto_mutate.json
resoto_access are the read permissions and mutate are the cleanup/label change permissions.
Once we tag the next release the "edge" part in the URI can also be replaced with the corresponding tag e.g. "3.5.2".
Motivation
There is currently documentation for the AWS permissions required to run Resoto https://resoto.com/docs/reference/permissions/aws but no documentation for the GCP implementation. It would be important to add the required permissions for GCP so we can understand the amount of access to provide the service account it is using.
Desired Behavior
An additional documentation page for Google Cloud permissions is to be created.
Additional Context
No response