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 only scan and and report resources visible to them. Ensure that your nodes are running CLI version 50.15.0 or greater.
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).\
Log in to the AWS Management Console for your organization.
Create an IAM role and add these polices:
The managed policy
AmazonEC2ReadOnlyThe managed policy
AmazonRDSReadOnlyA custom policy that you create to provide read-only access to list EKS clusters because there is not a managed policy for this
Ensure that your new role is attached to your EC2 instance(s) that you run the chosen node(s) on.
Continue node setup as necessary.
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).\
Log in to the Google Cloud console for your organization.
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-platformin thegcloud compute instances create ...command.Create a custom IAM role with the following permissions:
resourcemanager.projects.listcompute.zones.listcompute.instances.listcloudsql.instances.listcontainer.clusters.list
Assign the custom role to the service account of the Cloud Compute Engine where the StrongDM node is running.
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.projectBrowserroles/cloudsql.viewerroles/container.clusterViewerroles/compute.viewer
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:
Log in to the Azure portal for your organization.
Navigate to the VM hosting your node.
Select Security > Identity.
Click Azure role assignments.
Add the
Readerrole for the Subscription scope. Alternatively, you can create and use a custom role with the following permissions:Microsoft.ContainerService/managedClusters/readMicrosoft.Compute/virtualMachines/readMicrosoft.Sql/servers/readMicrosoft.Network/networkInterfaces/read
Lastly, set the following environment variables on your node:
AZURE_TENANT_IDAZURE_SUBSCRIPTION_IDThese values can be acquired in the Azure Portal (see the Microsoft documentation for more details on these values), and should be set in thesdm-proxyfile where you set StrongDM environment variables on your node. For gateways and relays, this is usually/etc/sysconfig/sdm-proxy, and for proxy cluster workers, it is usually/etc/sysconfig/sdm-proxy.
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
In the StrongDM Admin UI, go to the Settings > Connectors page. Here you see a list of current connectors. Select Add Connector.
Select a Cloud, and then choose a Name for the connector. Ideally, the name indicates 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 Selection menu. These should be the nodes that you configured to have read access to your cloud infrastructure in step 1. Selecting them here tags them with an
sdm__connector_idtag. The value of this tag is what is used to determine which nodes run a given scan.Select a value for Crawl interval to alter the frequency at which the connector crawls your cloud infrastructure and updates your discovered resources list.
Optionally, filter your scan results with Resource Matching options:
You can choose a Resource Type to limit the scan results to only resources of the selected type.
You can also include or exclude tags on the resource (cloud provider tags, not StrongDM tags) in order to include only resources with particular tags, or to exclude resources with particular tags.
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> failedmessage appears if it fails to start. The connector shows 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 changes status to Managed. On subsequent scans of your cloud, Virtual Machine A continues to be seen/discovered, and it continues 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 reconcile discovered resources with existing StrongDM resources unless tag based linking is performed.
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 shows up as a 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.
Select Manage Resource to begin onboarding the discovered resource.
The resulting modal has the Display Name of the resource in StrongDM prefilled to be the name of the discovered resource. You are 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.
Once you select a resource type, you are brought to the view to fill in the resource’s configuration. Some fields are 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.
AWS
RDS (RDS PostgreSQL)
EKS (EKS or EKS (Instance Profile))
GCP
Cloud SQL (various SQL datasource resource types)
GKE (GKE)
Azure
Azure SQL (Microsoft SQL server (Azure AD))
AKS (AKS)
Azure VM (various SSH server resource types)
Once the resource configuration is complete, select Save.
Once the resource is created, you are able to view it in Resources > Managed Resources.
In the Discovered Resources detail view for this item, under the Resources tab, there is a link to the managed resource within StrongDM.
Links between discovered and managed resources
When an admin creates a managed resource from a discovered resource, a tag is added to the managed resource in the format sdm__cloud_id=<PROVIDER_IDENTITY>. The PROVIDER_IDENTITY is dependent upon the cloud provider.
For Azure resources, this is the Resource ID.
For GCP resources, this is the Resource ID.
This feature is not yet offered for AWS resources, but is coming soon.
When StrongDM discovers a resource, it checks your existing managed resources for one that has a matching ID tag formatted as above, and if one exists, links them together so that you can see that the resource has already been onboarded as one or more StrongDM resources.
Automatically link managed and discovered resources
StrongDM allows you to automatically link managed and discovered resources. Many organizations use StrongDM to secure cloud resources and want to know if any cloud resources are created outside of those resources managed and protected in StrongDM. Setting up automatic linking allows you to know when an unprotected resource is added within the scope of your discovery scans. You can set up automatic linking by adding a tag to the managed resource in StrongDM that contains the resource's ID from the cloud provider. This ensures that the managed resource is matched to the discovered resource during a scan, and leaves you with a more accurate list of resources that are not yet secured through StrongDM.
To set up automatic linking, follow these steps:
For each cloud resource that you already manage in StrongDM, get the resource ID from your cloud provider and tag the resource in StrongDM. The tag should be in the format
sdm__cloud_id=<PROVIDER_IDENTITY>withPROVIDER_IDENTITYreplaced by the resource ID from your cloud provider.For Azure resources, this is the Resource ID.
For GCP resources, this is the Resource ID.
This feature is not yet offered for AWS resources, but is coming soon.
Run a scan when you set up a connector to your cloud provider in Settings > Connectors. When StrongDM scans your cloud, it matches an incoming discovered resource to any managed resource(s) that have a
sdm__cloud_id=<PROVIDER_IDENTITY>tag whose<PROVIDER_IDENTITY>matches the ID of the discovered resource.In the scan results, the automatically linked resources show up as managed. Due to the tag linking, the list of unmanaged resources now excludes all of the resources that are discovered but already existed in StrongDM, leaving you with a clear picture of what resources are currently not managed through StrongDM.
If you manually remove the link between a discovered and managed resource, StrongDM removes the tag on the managed resource so that it isn't linked in future scans
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 remains 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 (unless the managed resources are tagged as indicated in the section on automatic linking with tags).
If you manually unlink a managed resource from the discovered resource that it was attached to, the ID tag on the managed resource is removed.
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
Find the node(s) in the Admin UI at Networking > Gateways or Networking > Relays and check if it is healthy.
Make sure that your IAM role is attached to your node.
Check that the IAM role has the required read permissions for the resource types you intend to scan for.
Last updated
Was this helpful?