Introduction:
Have you ever found yourself in a situation where you needed to move a security connector in Defender for Cloud between subscriptions or tenant? This article provides guidance on important considerations for removing and re-creating security connectors for AWS/GCP in Microsoft Defender for Cloud. These security connectors store the configuration preferences that Defender for Cloud uses to access your AWS/GCP environment and provide security recommendations and alerts. There may be instances where you need to re-create the connector, such as following best practice guidance, connecting to a different Azure tenant, or storing connectors in different resource groups. I cover the process of re-creating the connector in more detail, including the creation of the connector, the deletion of the connector, and the re-creation of the connector.
Creating the security connector:
To onboard your AWS/GCP environment to Defender for Cloud, you need to create a security connector. As part of this process, you run a Cloud Formation template in AWS or a cloud shell script in GCP. These templates/scripts create the roles and resources that Defender for Cloud requires to provide security recommendations and alerts for your workloads. The resources and roles created in AWS/GCP depend on the Defender for Cloud plans you select on the security connector.
In AWS, the minimum set of roles and resources created by the template includes:
- Identity provider
- IAM roles
In GCP, the minimum set of roles and resources created by the script includes:
- Workload identity provider
- Workload identity pool
- Policy (role bindings)
The outcome of the security connector creation process is the creation of the connector as an Azure resource inside the selected subscription and resource group, as well as the roles and resources created in AWS/GCP. If you enable CWP capabilities and auto-provisioning, the Azure Arc agent and extensions also get installed on AWS/GCP compute resources such as servers, managed Kubernetes, and databases (figure 1).
Figure 1: Auto-provisioning the Azure Arc agent and extensions to your AWS/GCP workloads.
Deleting the security connector:
If you need to delete the security connector, you can do so through the Environment settings blade or via the Security Connectors REST API. This will delete the connector as an Azure resource inside the resource group and subscription selected during the creation process. However, it is important to note that deleting the connector in Defender for Cloud does not remove the roles and resources created by the template/script in AWS/GCP. After deleting the connector, it is your responsibility to properly delete these resources in AWS/GCP (like the AWS roles created by the security connector that are displayed in figure 2, note that some information is intentionally obfuscated).
Figure 2: Names of roles created on AWS (depending on the plans you select)
There is an additional consideration, if you enable CWP capabilities, on AWS/GCP compute resources such as servers, managed Kubernetes, and databases. Defender for Cloud will now automatically delete Azure Arc machines when those machines are deleted in connected AWS or GCP account. This applies to machine connected to an AWS and GCP account and covered by Defender for Servers or Defender for SQL on machines. After deleting the connector, it is your responsibility to properly remove the Azure Arc agent and extensions installed on any other resources in AWS/GCP. If you wish to offboard completely, additionally you need to delete the Azure Arc representations of these resources, in the resource group in which the security connector was stored.
If you're planning on re-creating the security connector, there are some exceptions to the above guidance:
- if you’re connecting the same AWS/GCP environment, to the same Azure tenant and are using the same Azure subscription, but different resource group to store the connector in, then you don’t need to delete the roles and resources that the security connector created in AWS/GCP.
- if you’re connecting the same AWS/GCP environment, to the same Azure tenant and are using different Azure subscription, and different resource group to store the connector in, then you don’t need to delete the roles and resources that the security connector created in AWS/GCP.
- if you’re connecting the same AWS environment, to a different Azure tenant and are using different Azure subscription, and different resource group to store the connector in, then it's highly recommended due to security reasons to delete the Stack/StackSet in AWS you used during the onboarding process.
- if you’re connecting the same GCP environment, to a different Azure tenant and are using different Azure subscription, and different resource group to store the connector in, then it's highly recommended due to security reasons to delete the old Workload identity pool and providers in GCP. Then you can create a new workload identity pool and providers in the management project and link the providers to pre-existing policy (role bindings).
Re-creating the security connector:
There are certain scenarios that warrant re-creating the security connector, for example you might want to store security connectors in different subscriptions or resource groups. If you need to re-create the security connector, you will need to follow the same process as outlined in the "Creating a security connector" section. Please note, you need to wait at least one minute after deleting the security connector in Azure, prior to re-creating it. When re-creating the security connector in the same Azure tenant, you don’t need to delete the roles and resources on the AWS/GCP side. However, if choose to do so you might need to wait longer until you're able to re-create the security connector, because in GCP there is a 'soft' delete for 30 days. The deletion in AWS is instantaneous.
Conclusion:
In summary, it is important to carefully consider the process of removing and re-creating security connectors in Microsoft Defender for Cloud. Properly deleting and re-creating these connectors requires following the correct process and properly deleting the resources and roles created in AWS/GCP. Following these steps will help ensure the security and effectiveness of your cloud environments.
Reviewers:
Or Serok Jeppa, Senior PM Manager
Ameer Abu Zhaia, Software Engineer II
Giulio Astori, Principal Product Manager
Contributors:
Ameer Abu Zhaia, Software Engineer II
Chemi Shumacher, Senior Software Engineer
