What you need to know when deleting and re-creating the security connector(s) in Defender for Cloud

[Guest Bojan Magusic]

Introduction:

 

This article provides guidance on important considerations for removing and re-creating security connectors 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. Deleting the security connector does not remove the Azure Arc agent and extensions that are installed after you enabled CWP capabilities. After deleting the connector, it is your responsibility to properly remove the Azure Arc agent and extensions installed on your 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/GCP environment, to a different Azure tenant and are using different Azure subscription, and different resource group to store the connector in, then you need to delete the roles and resources that the security connector created in in AWS/GCP.
  

 

 

 

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

 

Continue reading...