doitintl / cloud-catalog Goto Github PK

We should probably get rid of it and move the products elsewhere.

CC @eyalzek

azure resource azure/security-center has name Microsoft Defender for Cloud (which is already correctly being used for id azure/defender-for-cloud. It should probably be named "Microsoft Security Center" instead.

https://github.com/doitintl/cloud-catalog/blob/master/data/azure.json#L3072-L3092

Upon closer observation, the Url https://azure.microsoft.com/en-us/services/security-center/ redirects to https://azure.microsoft.com/en-us/services/defender-for-cloud/#overview, so I guess that either Security Center has been renamed or deprecated.

Reported by @haizaar here: https://doitintl.slack.com/archives/C01QGRRUBG9/p1674453980951869

Actually, a lot of workspace services are duplicated below gcp:

Example gcp endpoint management:

• GCP: gcp/endpoint-management
• G-Suite: gsuite/endpoint

The urls of these dupes all seem to have urls like this: https://cloud.google.comhttps://workspace.google.com/products/admin/endpoint, which leads me to believe this is actually a bug with scraping.

The current cloud catalog and how the services are used is brittle, requires regular manual intervention, and is prone to errors.
The cause of these issues are:

• cloud vendors can rename services at anytime (or remove them)
• cloud vendors can change the categories of a service at any time

This leads to issues where:

• we don't update CRE individually selected skills if the skill/product name changes in CC. This means no-one is supporting that specific service
• Old tickets with the original product name/skill won't be updated, breaking analytics
• Focus area mappings will become out of date when product names change, requiring manual intervention

We need to develop a more robust solution that solves the following use cases:

• customers get a comprehensive list of services to pick from in the DoiT Console
• services/FA selections by CREs map to these selections so we can route tickets appropriately
• changes to the cloud catalog can automatically be managed/resolved
• tickets with old product values don't get lost in analytics

I noticed that we have IAM duplicated, but with different product names. This is almost certainly an artifact from Google rather some bug in this repo.

https://github.com/doitintl/cloud-catalog/blob/master/data/gcp.json#L2981-L2986

Reported by John D'Elia on slack: https://doitintl.slack.com/archives/C01FTAT48P8/p1683147910345059?thread_ts=1683147101.730239&cid=C01FTAT48P8

I could swear we had something for GCP Maps stuff, but I can't seem to find it.
A case for custom-services/gcp.json, I guess.

/CC @hrisp

Examples:

• https://cloud.google.comhttps://workspace.google.com/products/admin/endpoint/
• https://cloud.google.comhttps://firebase.google.com/products/crashlytics/
• https://cloud.google.comhttps://marketingplatform.google.com/about/enterprise/#?modal_active=none
• https://cloud.google.comhttps://github.com/GoogleCloudPlatform/app-gradle-plugin
• https://cloud.google.comhttps://chronicle.security/products/virustotal/

etc...

I'm currently working on a new zendesk app to help with changing the product classification of tickets (See https://github.com/doitintl/zenrouter/issues/322 for context)
For this I would need access to the catalog files, which are already present in public bucket cloud_tags.
Since I want to try without a server, I would need to enable cors for the bucket.

Any objection to add the following cors configuration to the cloud_tags bucket?

[
    {
      "origin": ["*"],
    }
]

That would effectively allow everybody to use our json files even from web applications my other people. Since the bucket is already public, I don't see that much of an issue there. But still I'd like to get your opinion before I enable it.
An alternative would be to add all the instances of the new app that are currently in development as well as the production one, which can get messy (https://828401.apps.zdusercontent.com/, etc.).

I think the custom maps category for GCP is malformed.