Scoping Resources
Determining the scope of the audit is an extremely important concept in Vanta. Vanta will pull all resources in from your various integration environments by default unless you tell us otherwise! A resource can be anything from an employee account to a database from your cloud provider integration. Scoping can be done in a variety of ways, but here we'll cover how it's done via the API.
Let's begin by scoping accounts for our Identity Provider connection. We'll use Google Workspace as an example, but any integration connection with accounts will work! For this example, let's pull the user's email so we know which user we are scoping, as well as their unique identifier which will be used in the next step. We'll also check to see if this user is a Vanta admin, since admins intentionally cannot be marked out of scope.
query GetGoogleAccounts {
organization {
GsuiteUserList(first: 2) {
edges {
node {
email
isAdmin
uid
}
}
}
}
}
{
"data": {
"organization": {
"GsuiteUserList": {
"edges": [
{
"node": {
"email": "[email protected]",
"isAdmin": true,
"uid": "eyJNmYFjIiwidCI6IkdzdWl0ZVVzZXIiLCJ1IjoiMTAxOTk1ODYwMjI3NTcwOTk2MjQ0In0="
}
},
{
"node": {
"email": "[email protected]",
"isAdmin": false,
"uid": "eyNmY3mFjIiwidCI6IkdzdWl0ZVVzZXIiLCJ1IjoiMTEzMDgwMDQ3Nzc0MjM2Nzk3OTU0In0="
}
}
]
}
}
}
}
Now let's try our first mutation against the Vanta API. We will run the following mutation to adjust the scope of the Google user account from our previous query to false
.
Run in GraphQL Explorer (Note: You'll want to adjust the user's unique identifier to the uid
you pull from your previous query since the one in our example will not work for your Vanta domain!)
mutation Mutation {
setFetchedResourceScopes(input: { inScope: false, resourceUids: "eyNmY3mFjIiwidCI6IkdzdWl0ZVVzZXIiLCJ1IjoiMTEzMDgwMDQ3Nzc0MjM2Nzk3OTU0In0=" }) {
... on SetFetchedResourceScopesSuccess {
countChanged
countNotApplicable
}
}
}
{
"data": {
"setFetchedResourceScopes": {
"countChanged": 1,
"countNotApplicable": 0
}
}
}
Let's try an example with a cloud resource. First we will query to pull a list of VPCs from our connected AWS environment. (Note: You can try this with any cloud resource!) Let's request the VPC name and uid, as well as the AWS account and region the VPC is hosted in.
query AwsVPCList {
organization {
AwsVPCList(first: 2) {
edges {
node {
name
uid
account
region
}
}
}
}
}
{
"data": {
"organization": {
"AwsVPCList": {
"edges": [
{
"node": {
"name": "vpc-07e83jr9bc9b76e30",
"uid": "eyJkIjoiNWZjODCI6IkF3c6YXdzOmVjMjp1N0LTI6Nzg3ODc2MDc5MjA4OnZwYy92cGMtMDczNDNiYzliNzZlMjJjMzAifQ==",
"account": "787893847263",
"region": "us-east-2"
}
},
{
"node": {
"name": "vpc-03adiwj29djf0e10",
"uid": "eyJkIjoiNWZj6IkF3c1ZQQyIsjMjp1cy1lYXN0LTE6Nzg3ODc2MDc5MjA4OnZwYy92cGMtMDNhNTE1Mjk5MjhjMjBlMTAifQ==",
"account": "102937648594",
"region": "us-east-1"
}
}
]
}
}
}
}
Now let's adjust the scope to false
for both of the VPCs returned. (Remember to adjust the uid
we provide in the example to that of the resource you retrieved from your environment)
mutation Mutation {
setFetchedResourceScopes(input: { inScope: false, resourceUids:
[ "eyJkIjoiNWZjODCI6IkF3c6YXdzOmVjMjp1N0LTI6Nzg3ODc2MDc5MjA4OnZwYy92cGMtMDczNDNiYzliNzZlMjJjMzAifQ==", "eyJkIjoiNWZj6IkF3c1ZQQyIsjMjp1cy1lYXN0LTE6Nzg3ODc2MDc5MjA4OnZwYy92cGMtMDNhNTE1Mjk5MjhjMjBlMTAifQ==" ] }) {
... on SetFetchedResourceScopesSuccess {
countChanged
countNotApplicable
}
}
}
{
"data": {
"setFetchedResourceScopes": {
"countChanged": 2,
"countNotApplicable": 0
}
}
}
Updated 5 months ago
Let's look at how we can set service accounts as "Not a person"!