SGC - AWS - Missing AWS Workspace Instance in CMDB

[User697706]

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?

[Matthew_13]

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

[dcdunn]

<div>

  <p>Hi &mdash; can you clarify the technical basis for the statement that adding

  <code>workspaces:Describe*</code> permissions would allow the Service Graph Connector for AWS (SGC‑AWS)

  to discover Amazon WorkSpaces?</p>

  <p>The documented connector architecture suggests this is not possible:</p>

  <ol>

    <li>

      <strong>SGC‑AWS ingests only from AWS Config and AWS Systems Manager (SSM)</strong>.

      The connector does <em>not</em> execute arbitrary AWS service-specific Describe APIs during

      ingestion. This is explicitly stated in the SGC‑AWS Introduction (ingestion =

      Config for resource CIs, SSM for software/OS attributes).

      <!-- [1](https://fisglobal.sharepoint.com/sites/SNOWITOMDiscoveryTeam/Shared%20Documents/PRJ0015424%20SNOW%20...) -->

    </li>

    <li>

      <strong>The Functional Spec CI matrix does not list Amazon WorkSpaces as a supported CI type</strong>.

      Without a defined CI mapping, transform pipeline, or class target, the connector cannot ingest

      WorkSpaces even if IAM permissions are present. IAM alone cannot activate an unsupported ingestion

      path.

      <!-- [2](https://fisglobal.sharepoint.com/teams/5039/CLBTManagedServices/IRSMCS%20Technical%20Handover/ilija'...) -->

    </li>

    <li>

      <strong>The Diagnostic Tool documentation confirms the dependency chain</strong>

      (AWS Config + SSM + IAM) with no reference to WorkSpaces API consumption anywhere in the connector’s

      call graph.

      <!-- [3](https://teams.microsoft.com/l/meeting/details?eventId=AAMkAGI2YjAzNDUxLTQ2YzQtNDNjZi1iNDI3LWRhZDMzMz...) -->

    </li>

  </ol>

  <p>Given this, could you clarify <em>how</em> SGC‑AWS would ingest WorkSpaces data solely because the

  IAM role includes <code>workspaces:Describe*</code>, when the connector:</p>

  <ul>

    <li>does not call WorkSpaces APIs,</li>

    <li>does not list WorkSpaces as a supported CI type, and</li>

    <li>relies exclusively on Config/SSM for ingestion?</li>

  </ul>

  <p>If there is an undocumented ingestion path or an internal build adding WorkSpaces mapping, can you

  provide details on version, mapping implementation, and the intended CMDB class target?</p>

</div>

[User697706]

Thanks @Matthew_13 , I've given thumbs up for the helpful and prompt feedback. I'll work with the AWS engineer to get the permission added and shall see if we are getting Workspace CIs populated (under VMI class/cloud resource class, etc) 😄

[User697706]

Hi @Matthew_13 , 

The AWS engineer is adding permission for Workspace CIs however he found that this action does not exist. Is there any error or typo on this?

• workspaces:ListTagsForResource