Adds cloud.account.id #11
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The cloud.account.id can be a common field. All cloud providers have a high level account id, org id, or subscription id that can be used in this field. Anything more specific such as GCP's project id should go in an extended schema for the specific cloud provider. Its important to put GCP's project id in to a separate extended schema, because it does not overlap conceptually with other cloud providers' structure. For example. In GCP, you'll have an `organization id`. Under that `organization id`, you can have multiple projects. This diverges quite substantially from the flat AWS structure which is just a bunch of linked accounts. For AWS, there is no subtree like GCP has for projects or folders. Azure has a top level organization as well. Under that there are [subscriptions](https://docs.microsoft.com/en-us/office365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings). For security analytics use cases it will be difficult to normalize across all cloud providers, but account id could be the most basic start. Since high level orgs are pretty much consistent across all cloud providers, this could be in the common schema. _I'm open to calling this organization.id also_
ruflin
reviewed
Jun 1, 2018
| description: > | ||
| The cloud account or organization id | ||
|
|
||
| This could be the AWS account id or Google Cloud ORG Id. This should be |
There was a problem hiding this comment.
Let's remove the should be in an extended schema part here as we don't have that yet.
|
Sounds good to me, account ID is common to (almost?) all providers |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The cloud.account.id can be a common field. All cloud providers have a
high level account id, org id, or subscription id that can be used in
this field. Anything more specific such as GCP's project id should go in
an extended schema for the specific cloud provider. Its important to put
GCP's project id in to a separate extended schema, because it does not
overlap conceptually with other cloud providers' structure.
For example. In GCP, you'll have an
organization id. Under thatorganization id, you can have multiple projects. This diverges quitesubstantially from the flat AWS structure which is just a bunch of
linked accounts. For AWS, there is no subtree like GCP has for projects
or folders.
Azure has a top level organization as well. Under that there are
subscriptions.
For security analytics use cases it will be difficult to normalize
across all cloud providers, but account id could be the most basic
start. Since high level orgs are pretty much consistent across all cloud
providers, this could be in the common schema.
I'm open to calling this organization.id also