Resource Discovery

Resource discovery is a tool to use to discover public cloud resources and then onboard them for management in StrongDM quickly and efficiently. You can run nodes in your public cloud, grant them the appropriate scanning permissions, and then configure connectors. This updates a list in StrongDM of resources within that cloud and provides a way to onboard supported resource types easily, adding them to your StrongDM organization as managed resources. Resource discovery makes it significantly easier to onboard the cloud infrastructure for your organization into StrongDM, particularly if that infrastructure is extensive.

Currently, AWS, GCP, and Azure are supported as cloud providers for resource discovery.

• The AWS resources supported for discovery at this time are EC2, RDS, and EKS.

• The GCP resources supported for discovery at this time are GCE, Cloud SQL, and GKE.

• The Azure resources supported for discovery at this time are Virtual Machines, SQL servers, and AKS instances.

Node Setup

Choose or create the StrongDM node(s) you wish to use to scan your cloud infrastructure. These nodes need read access to your cloud infrastructure. Although it possible to configure nodes running outside your cloud with scanning permissions, we recommend the easier path of simply running nodes inside the cloud organization you wish to scan. If you want to limit the node's visibility into your cloud (for example, limiting scanning to a certain account, project, or application), you can grant read access only to those resources using your cloud provider's IAM feature. Nodes will only scan and and report resources visible to them. Ensure that your nodes are running CLI version 50.15.0 or greater.

AWS

In AWS, there are a variety of ways to host StrongDM nodes (gateways, relays, or workers) that can conduct scans. The following configuration example assumes that you are using an EC2 instance within the same organization. The permissions listed are those useful to scan for all resource types supported currently by StrongDM (EC2, RDS, and EKS clusters).

1. Log in to the AWS Management Console for your organization.

2. Create an IAM role and add these polices:

   • The managed policy AmazonEC2ReadOnly

   • The managed policy AmazonRDSReadOnly

   • A custom policy that you create to provide read-only access to list EKS clusters because there is not a managed policy for this

3. Ensure that your new role is attached to your EC2 instance(s) that you run the chosen node(s) on.

4. Continue node setup as necessary.

GCP

In GCP, there are a variety of ways to host StrongDM nodes (gateways, relays, or workers) that can conduct scans. The following configuration example assumes that you are using a GCE instance within the same organization. The permissions listed are those useful to scan for all resource types supported currently by StrongDM (GCE, Cloud SQL, and GKE clusters).

1. Log in to the Google Cloud console for your organization.

2. Identify or create a Compute Engine (GCE) to run your node. Ensure that this instance has the cloud-platform OAuth Scope. If you are creating a new GCE instance, specify --scopes=https://www.googleapis.com/auth/cloud-platform in the gcloud compute instances create ... command.

3. Create a custom IAM role with the following permissions:

   • resourcemanager.projects.list

   • compute.zones.list

   • compute.instances.list

   • cloudsql.instances.list

   • container.clusters.list

4. Assign the custom role to the service account of the Cloud Compute Engine where the StrongDM node is running.

5. Continue node setup as necessary.

As an alternative to the custom role, you can instead assign the GCE instance the following built-in roles:

• roles/resourcemanager.projectBrowser

• roles/cloudsql.viewer

• roles/container.clusterViewer

• roles/compute.viewer

Azure

In Azure, there are a variety of ways to host StrongDM nodes (gateways, relays, or workers) that can conduct scans. The following configuration example assumes that you are using an Azure VM within the same organization. The permissions listed are those useful to scan for all resource types supported currently by StrongDM (VMs, SQL servers, and AKS clusters).

If you are using Azure, hosting your scanning node(s) in Azure VMs within the same organization, and scanning for VMs, SQL servers, and AKS clusters, the following steps are required:

1. Log in to the Azure portal for your organization.

2. Navigate to the VM hosting your node.

3. Select Security > Identity.

4. Click Azure role assignments.

5. Add the Reader role for the Subscription scope. Alternatively, you can create and use a custom role with the following permissions:

   1. Microsoft.ContainerService/managedClusters/read

   2. Microsoft.Compute/virtualMachines/read

   3. Microsoft.Sql/servers/read

   4. Microsoft.Network/networkInterfaces/read

6. Lastly, set the following environment variables on your node:

   1. AZURE_TENANT_ID

   2. AZURE_SUBSCRIPTION_ID

   These values can be acquired in the Azure Portal. See the Microsoft documentation for more details.

Connectors

Connectors are a collection of selected nodes and configuration for how they can discover information about your resources, when, and from where. You can get started with connectors by following these steps.

Set up a connector

1. In the StrongDM Admin UI, go to the Settings > Connectors page. Here you see a list of current connectors. Select Add Connector.

2. Select a Cloud, and then choose a Name for the connector. Ideally, the name will indicate which cloud account or environment you wish to discover resources in. A Description is optional and can provide further context. Lastly, select one or more of your nodes from the Node(s) dropdown menu. These should be the nodes that you configured to have read access to your cloud infrastructure in step 1.

3. Select a value for Crawl interval to alter the frequency at which the connector crawls your cloud infrastructure and updates your discovered resources list.

4. Now the connector is set up. It specifies which nodes to use to run the scan and against which type of cloud. The nodes have been configured with the access they need. Your scans run automatically at whatever period of time you set your Crawl interval to be. This is the primary way to update your discovered resources list, but you can run a manual scan to start off if you don't want to wait. Select Actions > Run Scan to run your scan. A green checkmark briefly appears in the bottom right corner of the Admin UI if the scan started successfully. A red <CONNECTOR_NAME> failed message appears if it fails to start. The connector will show a failure message if you start a manual scan while a scan is already running. You can view a connector's scan history by clicking on the connector name to display the connector details page.

Discovered Resources

Discovered resources are the infrastructure within your cloud provider that are discovered by scans that you run with connectors. Discovered resources shown in the Admin UI on the Discovered Resources page are shown in a list with their name, tags, and status:

• Name: External name of this discovered resource in the cloud provider (not a StrongDM resource name)

• Cloud: Cloud provider that this resource was discovered in

• Kind: Type of cloud resource discovered

• Tags: Tags associated with this discovered resource in the cloud provider. You may overwrite these tags when creating a managed resource from the discovered resource

• Status:

  • Managed (onboarded as one or more resource(s) in StrongDM)

  • Unmanaged (discovered but not yet onboarded into StrongDM)

• First Seen: Date/time stamp of when this resource was first seen in a scan

• Last Seen: Date/time stamp of when this resource was last seen in a scan

Currently, the discovery feature does not automatically reconcile discovered resources with existing managed resources in StrongDM. Instead, StrongDM moves discovered resources from the Unmanaged to the Managed status when you use the onboarding feature to manage a discovered resource manually. For instance, consider the following example scenarios.

Scenario 1: Existing managed resource

You discover Virtual Machine A from the cloud and use the Manage button to onboard it as a managed resource. Virtual Machine A will change status to Managed. On subsequent scans of your cloud, Virtual Machine A will continue to be seen/discovered, and it will continue to show as a managed resource.

Scenario 2: No existing managed resource

You were already using Virtual Machine B as a resource in StrongDM before using the discovery feature. When you scan your cloud, Virtual Machine B shows in the scan results in the Unmanaged status until you use the Manage action to onboard it as a new managed resource. The discovery process does not currently reconcile newly discovered resources with existing StrongDM resources.

Scenario 3: Deleted and rediscovered managed resource

You discover Virtual Machine C from the cloud, use the Manage button to onboard it as a managed resource, and then later delete both the managed resource in StrongDM and the Virtual Machine in your cloud provider. If you then recreate the Virtual Machine and a new StrongDM scan picks it up, it will show up as a newly discovered, unmanaged resource, with no connection to the previously managed resource.

Onboard a discovered resource

When viewing the discovered resource details, you can onboard the discovered resource to make it a managed resource in StrongDM.

1. Select Manage Resource to begin onboarding the discovered resource.

2. The resulting modal has the Display Name of the resource in StrongDM prefilled to be the name of the discovered resource. You will be prompted to select a Resource Type.

Although the type of resource has already been detected in the scan, choosing a StrongDM resource type is still necessary. This is because for many kinds of infrastructure there are multiple StrongDM resource types available, each reflecting a different kind of connection or authentication.

1. Once you select a resource type, you are brought to the view to fill in the resource’s configuration. Some fields will be auto-filled based on discovered information about the resource. Fill in the rest of the fields appropriately. See the StrongDM resource configuration guides for more details on those fields.

   1. AWS

      1. RDS (RDS PostgreSQL)

      2. EKS (EKS or EKS (Instance Profile))

      3. EC2 (various SSH server resource types)

   2. GCP

      1. Cloud SQL (various SQL datasource resource types)

      2. GKE (GKE)

      3. GCE (various SSH server resource types)

   3. Azure

      1. Azure SQL (Microsoft SQL server (Azure AD))

      2. AKS (AKS)

      3. Azure VM (various SSH server resource types)

2. Once the resource configuration is complete, select Save.

Once the resource is created, you are able to view it in Resources and whichever subcategory (Servers, Datasources, or Clusters) is appropriate for your resource type. In the discovered resources detail view for this item, you will see under the Resources tab a link to the managed resource within StrongDM. Note that the link between the “discovered resource” and the resource in StrongDM are broken if the discovered resource is removed from your cloud, or if the managed resource is deleted in StrongDM. See the discovered resource considerations section for more detail.

Discovered resource considerations

• Items in the Discovered Resources view can’t be deleted through StrongDM, as they are simply the latest information gathered by scans of your infrastructure.

• Discovered resource data in StrongDM is not authoritative. StrongDM is not the source of truth for what exists in your infrastructure, and the information that is captured is only regarding the resources that were running and that you’ve given your StrongDM nodes permission to see.

• One discovered resource can be onboarded into many StrongDM managed resources, preserving the ability to make many resources with different credentials and permissions to provide varying levels of access to the same cloud resource.

• Currently, there is no way to automatically delete a resource in StrongDM when the linked “discovered resource” is decommissioned in the cloud and no longer visible from scans.

• The link between a scanned (discovered) resource and an onboarded resource indicates only the origin of the latter. The link is not maintained as changes to the underlying cloud resource occur. If you, for example, change the hostname of a cloud resource to something different than what was discovered originally, that item in the Discovered Resources view will remain linked to the StrongDM resource. This also means that resources that are taken offline, removed from the list, and then added again in later scans are added as new, unlinked discovered resources.

Logs

The following logs are recorded in StrongDM regarding resource discovery:

• Admin activities are logged when connectors are created, updated, or deleted.

• Admin activities are logged when a discovered resource is onboarded to a StrongDM resource.

• Node logs record events with the results of scans that they run against your cloud infrastructure. Currently, there is no Admin UI activity for scan results.

Troubleshooting

1. Find the node(s) in the Admin UI at Networking > Gateways or Networking > Relays and check if it is healthy.

2. Make sure that your IAM role is attached to your node.

3. Check that the IAM role has the required read permissions for the resource types you intend to scan for.