SGC - AWS - Missing AWS Workspace Instance in CMDB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
We are running SGC‑AWS(without SSM deep discovery) successfully for standard AWS resources - EC2, VPC, ENI, ELB, RDS, S3, DynamoDB, EKS, etc. However it appears that we are missing the Instances for AWS Workspaces.
I understand that it is possible to populate these AWS Workspace Instance via SGC-AWS as well. May I know what is missing? Could it be the extra IAM policy that need to be added from the AWS ? If yes, may I know what is the recommended IAM policy to include AWS Workspace to be discovered and populates to CMDB?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Welcome back I see your last post was in 2023......
From my experience, this is expected behavior with SGC-AWS (without SSM deep discovery).
By default, the SGC-AWS connector does not discover AWS WorkSpaces because they are a separate AWS service and are not returned through the standard EC2 APIs that SGC uses for most compute discovery. As a result, WorkSpaces won’t show up in CMDB unless the connector’s IAM role has explicit permission to query the WorkSpaces APIs.
What’s missing in your setup is additional IAM read permissions for AWS WorkSpaces.
At a minimum, the IAM role used by SGC-AWS needs permissions such as:
workspaces:DescribeWorkspaces
workspaces:DescribeWorkspaceDirectories
workspaces:DescribeWorkspaceBundles
workspaces:DescribeTags / ListTagsForResource
The recommended approach is to allow read-only access to all WorkSpaces “Describe” actions for example:
workspaces:Describe*
workspaces:ListTagsForResource
Once these permissions are added and the connector is rerun, WorkSpaces should be discovered and populated in CMDB. Keep in mind that without SSM, discovery will be metadata only Workspace ID, directory, bundle, state, region, not OS level details, and the CIs may land under cloud/VDI-related classes rather than standard EC2 serveer classes.
So:
Yes, this is an IAM policy gap
WorkSpaces require explicit WorkSpaces API permissions
Behavior is expected in the latest builds of SGC-AWS without SSM
@User697706 - Please mark Accepted Solution and Thumbs Up if you find Helpful
