Jump to content
Updated Privacy Statement
  • Guest
    Citrix Ansible modules for NetScaler are hosted in this GitHub repository. There you will find an assortment of modules that utilize a specific NITRO API endpoint. Each of these resources will implement a CRUD lifecycle for each endpoint taking into account the peculiarities that particular endpoint may have. While this model is fine it requires for each endpoint the creation of a module that may have many similarities to existing ones. Hence, we have a generic module citrix_adc_nitro_resource which implements the CRUD operations in a generic manner applicable to multiple endpoints. You can use generic module citrix_adc_nitro_resource if you dont find a dedicated module for the usecase you are targeting.

    How NetScaler Nitro Resource module works ?The citrix_adc_nitro_resource module will accept as parameters a dictionary which describes the workflow of the endpoint the attributes for this particular endpoint and the attributes required to connect to the target NetScaler. Then it will compare the local and remote state and decide on the operation it needs to perform. It will update the changed status variable and report this back to Ansible. Let’s see what a typical use of the module looks like :
    - name: Setup nitro resource lb group delegate_to: localhost citrix_adc_nitro_resource: nsip: "{{ nsip }}" nitro_user: "{{ nitro_user }}" nitro_pass: "{{ nitro_pass }}" state: present workflow: lifecycle: object endpoint: lbgroup primary_id_attribute: name resource_missing_errorcode: 258 allow_recreate: true resource: name: mylbgroup timeout: 160The invocation of the module is very similar to the other modules. It takes the connection information for the NITRO API, the state variable which will determine if the NITRO object must be created/updated, or destroyed.
    Additionally, it takes the workflow variable which is a dictionary that will decide what NITRO API calls to make to implement the CRUD operations. This dictionary is the one that will differentiate the execution for the various endpoints and make the correct checks for the existence and equality of the local and remote states.
    The most important attribute is the lifecycle attribute which will determine the code path taken inside the module. The endpoint attribute is the one that determines the url that will be used for this NITRO object. The rest of the attributes have a special meaning depending on the lifecycle attribute. In this case we can see that name is the attribute that uniquely identifies this NITRO object, 258 is the error code returned when the resource is missing, and allow_recreate defines that should a recreate instead of an update operation is needed it is allowed.
    The values for this dictionary could be provided by the user but since this requires an intimate knowledge of the NITRO API and the code of the nitro_resource module we provide a reference for this dictionary in our github repository. It can be found here.
    You can use it in your playbook by referencing it as a variable
    vars_files: - deps/workflows.yaml… workflow: "{{ workflow.lbgroup }}"
    Finally, it takes the resource option which is the dictionary containing the attributes of the NITRO object.
    In this dictionary, we define the NITRO object attributes. You need to know which attributes are applicable for each endpoint. The reference for the NITRO API can be found here.
    Additionally for the CRUD operations to work correctly the attributes must be the same data type as returned by the NITRO API. For example, a number that is returned as a string must be provided as a string in this dictionary. Otherwise, the module will report that the configured object is not the same as the remote object on the target NetScaler.
    While this module is very useful in creating, updating, and deleting a NITRO object it cannot perform all operations permissible by the NITRO API for an endpoint.As an example, the enable/disable action for a basic server cannot be implemented with the nitro_resource module.
    For this, the user will have to use the other generic module we have citrix_adc_nitro_request, which we have covered in a separate post.
    Useful Links
    NetScaler Ansible modules repository ( https://github.com/citrix/citrix-adc-ansible-modules )Nitro resource examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_resource )
    Nitro request examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_request )

    Need for Intelligent Routing
    In today’s complex websites, you might want to present different content to different users. You might want to present content relevant to a specific geographical area to users from that area. You might want to present content in different languages to the speakers of those languages. You might want to present content tailored to specific devices, such as smartphones, to them who use the devices. The NetScaler content switching feature enables the appliance to distribute client requests across multiple servers based on specific content that you want to present to those users.
    NetScaler Content Switching
    NetScaler Content Switching configuration entails enabling the content switching feature, setting up load balancing for the server or servers that host each version of the content that is being switched, creating a content switching virtual server, creating policies to choose which requests are directed to which load balancing virtual server, and binding the policies to the content switching virtual server. You can then customize the setup to meet your needs by setting precedence for your policies, protecting your setup by configuring a backup virtual server, and improving the performance of your setup by redirecting requests to a cache. You can learn more about it here.
    Content Switching Example using Terraform
    The following example shows the steps to configure two address-based virtual servers to perform load balancing on the HTTP services. One virtual server, Vserver-LB-HTML, load balances the dynamic content (cgi, asp), and the other, Vserver-LB-Image, load balances the static content (GIF, jpeg). The load-balancing method used is the default, LEASTCONNECTION. A content switching SSL virtual server, Vserver-CS-SSL, is then configured to perform SSL acceleration and switching of HTTPS requests based on configured content switching policies. Below is an terraform resource file for above use-case :
    resource "citrixadc_lbvserver" "lb_1" { name = var.lbvserver1_name ipv46 = var.lbvserver1_ip port = var.lbvserver1_port servicetype = var.lbvserver1_servicetype state = "ENABLED"}resource "citrixadc_lbvserver" "lb_2" { name = var.lbvserver2_name ipv46 = var.lbvserver2_ip port = var.lbvserver2_port servicetype = var.lbvserver2_servicetype state = "ENABLED"}resource "citrixadc_service" "tf_service1" { name = var.service1_name servicetype = var.service1_servicetype ipaddress = var.service1_ip ip = var.service1_ip port = var.service1_port state = "ENABLED"}resource "citrixadc_service" "tf_service2" { name = var.service2_name servicetype = var.service2_servicetype ipaddress = var.service2_ip ip = var.service2_ip port = var.service2_port state = "ENABLED"}resource "citrixadc_service" "tf_service3" { name = var.service3_name servicetype = var.service3_servicetype ipaddress = var.service3_ip ip = var.service3_ip port = var.service3_port state = "ENABLED"}resource "citrixadc_service" "tf_service4" { name = var.service4_name servicetype = var.service4_servicetype ipaddress = var.service4_ip ip = var.service4_ip port = var.service4_port state = "ENABLED"}resource "citrixadc_lbvserver_service_binding" "tf_binding1" { name = citrixadc_lbvserver.lb_1.name servicename = citrixadc_service.tf_service1.name}resource "citrixadc_lbvserver_service_binding" "tf_binding2" { name = citrixadc_lbvserver.lb_1.name servicename = citrixadc_service.tf_service2.name}resource "citrixadc_lbvserver_service_binding" "tf_binding3" { name = citrixadc_lbvserver.lb_2.name servicename = citrixadc_service.tf_service3.name}resource "citrixadc_lbvserver_service_binding" "tf_binding4" { name = citrixadc_lbvserver.lb_2.name servicename = citrixadc_service.tf_service4.name}resource "citrixadc_csvserver" "tf_csvserver" { name = var.csvserver_name ipv46 = var.csvserver_ipv46 port = var.csvserver_port servicetype = var.csvserver_servicetype state = "ENABLED" stateupdate = "ENABLED"}resource "citrixadc_cspolicy" "tf_cspolicy1" { policyname = var.cspolicy1_name url = var.cspolicy1_url}resource "citrixadc_cspolicy" "tf_cspolicy2" { policyname = var.cspolicy2_name url = var.cspolicy2_url}resource "citrixadc_cspolicy" "tf_cspolicy3" { policyname = var.cspolicy3_name url = var.cspolicy3_url}resource "citrixadc_cspolicy" "tf_cspolicy4" { policyname = var.cspolicy4_name url = var.cspolicy4_url}resource "citrixadc_csvserver_cspolicy_binding" "tf_bind1" { name = citrixadc_csvserver.tf_csvserver.name policyname = citrixadc_cspolicy.tf_cspolicy1.policyname targetlbvserver = citrixadc_lbvserver.lb_1.name}resource "citrixadc_csvserver_cspolicy_binding" "tf_bind2" { name = citrixadc_csvserver.tf_csvserver.name policyname = citrixadc_cspolicy.tf_cspolicy2.policyname targetlbvserver = citrixadc_lbvserver.lb_1.name}resource "citrixadc_csvserver_cspolicy_binding" "tf_bind3" { name = citrixadc_csvserver.tf_csvserver.name policyname = citrixadc_cspolicy.tf_cspolicy3.policyname targetlbvserver = citrixadc_lbvserver.lb_2.name}resource "citrixadc_csvserver_cspolicy_binding" "tf_bind4" { name = citrixadc_csvserver.tf_csvserver.name policyname = citrixadc_cspolicy.tf_cspolicy4.policyname targetlbvserver = citrixadc_lbvserver.lb_2.name}resource "citrixadc_sslcertkey" "tf_sslcertkey" { certkey = var.sslcertkey_name cert = var.sslcertkey_cert key = var.sslcertkey_key}resource "citrixadc_sslvserver_sslcertkey_binding" "tf_binding" { vservername = citrixadc_csvserver.tf_csvserver.name certkeyname = citrixadc_sslcertkey.tf_sslcertkey.certkey}In below, examples.tfvars file we have the input values and the definition of policies based on which routing decision will be taken :
    # Lb_Vserver1lbvserver1_name = "Vserver-LB-HTML"lbvserver1_ip = ""lbvserver1_port = 80lbvserver1_servicetype = "HTTP"# Lb_Vserver2lbvserver2_name = "Vserver-LB-Image"lbvserver2_ip = ""lbvserver2_port = 80lbvserver2_servicetype = "HTTP"# Service 1service1_name = "s1"service1_ip = ""service1_port = 80service1_servicetype = "HTTP"# Service 2service2_name = "s2"service2_ip = ""service2_port = 80service2_servicetype = "HTTP"# Service 3service3_name = "s3"service3_ip = ""service3_port = 80service3_servicetype = "HTTP"# Service 4service4_name = "s4"service4_ip = ""service4_port = 80service4_servicetype = "HTTP"# CS Vservercsvserver_name = "Vserver-CS-SSL"csvserver_ipv46 = ""csvserver_port = 443csvserver_servicetype = "SSL"# CS Policy 1cspolicy1_name = "pol1"cspolicy1_url = "/*.cgi"# CS Policy 2cspolicy2_name = "pol2"cspolicy2_url = "/*.asp"# CS Policy 3cspolicy3_name = "pol3"cspolicy3_url = "/*.gif"# CS Policy 4cspolicy4_name = "pol4"cspolicy4_url = "/*.jpeg"# SSL CertKeysslcertkey_name = "mykey"sslcertkey_cert = "/nsconfig/ssl/ns-root.cert"sslcertkey_key = "/nsconfig/ssl/ns-root.key"On running the above terraform scripts on your target NetScaler you can set up intelligent routing for the above use case. You can download the above scripts and learn about terraform execution here.


    Ansible Resources

    By Guest, in NetScaler Automation,

    Here are the resources for NetScaler Automation with Ansible:-
    NetScaler Configuration :
    Ansible modules to configure NetScaler NetScaler Configs example in Ansible   ADM Configuration :
    Ansible modules for ADM Get Started with Ansible Automation :
    Get Started with Ansible Automation Hands on Lab with Ansible Example of SSL Offloading configuration with Ansible Automate NetScaler with Ansible-whitepaper Let us know in the comments section if you need anything else on NetScaler automation with Terraform. 

    Here are the automation resources to get started with NetScaler in public cloud :-
    NetScaler in AWS
    CFTs to provision NetScaler VPX on AWS Get Started with NetScaler in AWS Demo Video :  Terraform cloud scripts to deploy NetScaler in AWS Demo Video :  NetScaler in Azure
    ARM templates to provision NetScaler VPX on Azure Terraform cloud scripts to deploy NetScaler in Azure NetScaler in GCP
    GDM templates to provision NetScaler VPX on Google Terraform cloud scripts to deploy NetScaler in GCP
    Let us know in the comments section if you need anything else on public cloud deployments

    CADS service with its premium entitlement has features like WAF and BOT to secure and protect your application from security threats. This guide will help you to deploy AWS firewall with CADS service. This is recommended if you have a CADS service Advance entitlement.  
    Deploy a data center and create NetScaler infrastructure on AWS cloud. Configure network settings in this public cloud data center with AWS firewall in a way that is completely transparent to the application users. 
    Following are the key requirements:  
    Distributed AWS Network Firewall deployment model: AWS Network Firewall is deployed into each individual VPC. 
    All end user, Nerscaler management, traffic should route through AWS network firewall.  
    Following tasks are expected to be completed for using this solution and successful integration. 
    CADS Service Application delivery configuration  
    AWS console access with permission to configure AWS Network Firewall and network routes 
    For the distributed deployment model, we deploy AWS Network Firewall into each VPC which requires protection. Each VPC is protected individually. Each VPC does not require connectivity to any other VPC or AWS Transit Gateway. Each AWS Network Firewall can have its own firewall policy or share a policy through common rule groups (reusable collections of rules) across multiple firewalls. This allows each AWS Network Firewall to be managed independently, which reduces the possibility of misconfiguration and limits the scope of impact. 
    Figure 1: AWS Network Firewall Distributed deployment in each protected VPC 
    Depending on the workload and traffic pattern, there are a number of AWS Network Firewall deployment models to consider. In the following section we will see a deployment model to protect traffic between NetScaler’s client subnet and IGW. 
    Figure2. AWS Network Firewall is deployed to inspect traffic between the internet and NetScaler/NAT gateway 
    ADS service control plane 
    Citrix Cloud / PoP 
    Deployed in secure Citrix owned PoP network outside of customer VPC 
    ADS Service Agent 
    VPC-n AZ-n 
    For communication with NetScaler Service control plane 
    Autoscaling NetScaler 
    VPC-n AZ-n 
    NetScaler data plane  
    VPC Connectivity 
    Via AWS Firewall 
    Via AWS Firewall 
    NATted External application users 
    Back end server group 
    Group of EC2 Instances forming Autonomous System (AS) 
    Create an AWS Firewall and share Firewall endpoint ENI (in this example: vpce-0aa4d4642c13726dc) 
    Point the ADS NetScaler route table to redirect client traffic to Firewall ENI 
    Add few rules on firewall policy and verify if the rules are being hit 
    Result: Request is being dropped as per the policy configured 
    Traffic Flows: 
    Client Traffic: 
    User access the application URL : http/s://<FQDN>/ 
    After DNS resolution, Client request lands on AWS Network firewall 
    From the firewall, user request is sent to internal NLB for Application Endpoint (Vserver) selection 
    Application request is sent to the Application Endpoint  
    After LB decision, request is forwarded to the EC2 instances and server response is sent back to the user  
    Server Traffic:  
    From NetScaler ASG traffic is load balanced across all the configured backend servers configured in the respective AZ. 
    This is a single VPC deployment, hence there are no inter VPC routing required for active traffic.  
    Return traffic goes via the AWS firewall to the client. 

    Bhalchandra Chaudhari
    For large organizations where NetScaler infrastructure is shared across many teams, and have 100s or 1000s of Apps delivered via NetScaler, maintaining NetScaler app centric configurations and the common/global configurations is big challenge and incurs maintenance overhead. Moreover, the NetScaler configurations need to be maintained for multiple environments such as dev, qa, and prod.
    Citrix ADC Terraform provider can help you to automate and manage the NetScaler configurations declaratively and, in an infrastructure-as-code fashion. Moreover, parent-child structure in Terraform can be employed to create 2 abstraction layers – the child layer containing the configurations of underlying NetScaler entities and the parent layer containing the app-centric configurations along with common NetScaler platform configurations. This approach provide multiple benefits as follows :-
    Avoid code duplication Abstracts the underlying NetScaler networking configurations Easier administration, config updates and troubleshooting Reduces time to release app updates In this article , we will see how this parent-child structure works in Terraform along with an example of ssl offloading 
    Parent-Child Architecture using Terraform Modules
    Parent-Child terraform terminology works at each terraform directory/module levels. The parent/root directory would be always as current working directory when you calling another terraform child module in that root directory which execute that child module configuration files (can be called as child configuration module). Similar way, organizations need to deal with shared resources which could been utilized by many entities( shared resource child module) which values can be simply pass to root module to be used as reference with root module entities such as SSL vServers, services etc.
    Modules – are containers for multiple resources that are used together consists of a collection of .tf files kept together in a directory. Root/Parent module- The main way to package and reuse resource configuration Containing all require .tf files in the main working directory Child modules- A submodule which can be called by root or parent modules Can be called multiple times within same root or different root modules  
    SSL Offloading using Terraform Modules
    Below is the SSL offloading created using terraform parent-child deployment –
    Child Modules prepared to call in root/parent module:
    SSL certificate keypair  SSL cipher group for frontend traffic SSL cipher group for backend traffic SSL virtual server configuration and parameters set SSL load balancing services Parent/Root modules:Application specific module e.g., example<.>com Below is the directory structure prepared for this deployment –├───citrixadc                                  - Citrix ADC terraform provider files
    ├───example.com                            - application root/parent directory/module
    ├───modules                                   - child module main directory
    │            ├───cipher_svc                               - child (shared) module backend cipher group
    │            ├───cipher_vs                                 - child (shared) module frontend cipher group
    │            ├───lbservice                                  - child (configuration) module load balancing services
    │            ├───lbvs-ssl                                    - child (configuration) module creates SSL vServer & parameters
    │            └───sslcertkeypair                           - child module add SSL certificate keypair
    └───sslcerts                                    - SSL files (cert and key) directory
    Above each directory module contain its own terraform files to prepare the configuration plan and helps root module to execute the configuration depends on variable attributes/parameters values.
    Below structure depicts each main directory module and sub-directory (child module) with respective terraform files –

    │             provider.tf
    │             resources.tf
    │             terraform.tfvars
    │              variables.tf
    │              versions.tf

    │   ├───cipher_svc
    │   │                       output.tf
    │   │                       README.md
    │   │                      resources.tf
    │   │
    │   ├───cipher_vs
    │   │                      output.tf
    │   │                      README.md
    │   │                      resources.tf
    │   │
    │   ├───lbservice
    │   │                      output.tf
    │   │                      README.md
    │   │                      resources.tf
    │   │                      variables.tf
    │   │
    │   ├───lbvs-ssl
    │   │                      output.tf
    │   │                      README.md
    │   │                      resources.tf
    │   │                      variables.tf
    │   │
    │   └───sslcertkeypair
    │                           output.tf
    │                           README.md
    │                           resources.tf
    │                           variables.tf

    You can find the terraform files of main root module “example”  here , where the resource block of each child module being called to configure require entity for load balancing.
    Executing Terraform to push SSL Offloading Configs
    On running terraform init, terraform plan and terraform apply, the module creates all the require entities and binding between them as shown below.
    You must run terraform init to initialize all child modules:
    PS C:\Users\bhalchandrac\ssloffload\example.com> terraform init                             
    Initializing modules...
    - ciphergroupname in ..\modules\cipher_svc
    - lbvserverssl in ..\modules\lbvs-ssl
    - loadbalancingservices in ..\modules\lbservice
    - sslcertkeyname in ..\modules\sslcertkeypair
    - vsciphergroupname in ..\modules\cipher_vs
    Initializing the backend...
    Initializing provider plugins...
    - Finding latest version of citrix/citrixadc...
    - Installing citrix/citrixadc v1.23.1...
    - Installed citrix/citrixadc v1.23.1
    Run terraform apply to push all the configs to ADC as shown below:
    PS C:\Users\bhalchandrac\article\example.com> terraform apply -var-file="../secret.tfvars" 
    Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
      + create
    Terraform will perform the following actions:
    Do you want to perform these actions?
      Terraform will perform the actions described above.
      Only 'yes' will be accepted to approve.
      Enter a value: yes
     module.sslcertkeyname.citrixadc_systemfile.sslkey: Creating...
    module.loadbalancingservices.citrixadc_server.tf_server["testserver12"]: Creating...
    module.sslcertkeyname.citrixadc_systemfile.sslcert: Creating...
    module.loadbalancingservices.citrixadc_server.tf_server["testserver11"]: Creating...
    module.lbvserverssl.citrixadc_lbvserver.tf_lbvserverssl: Creating...
    citrixadc_lbvserver.tf_lbvserverhttp: Creating...
    module.ciphergroupname.citrixadc_sslcipher.tf_sslcipher: Creating...
    module.vsciphergroupname.citrixadc_sslcipher.tf_sslcipher: Creating...
    module.loadbalancingservices.citrixadc_server.tf_server["testserver12"]: Creation complete after 4s [id=testserver12]
    module.sslcertkeyname.citrixadc_systemfile.sslcert: Creation complete after 5s [id=/flash/nsconfig/ssl/terracert.cert]
    module.loadbalancingservices.citrixadc_server.tf_server["testserver11"]: Creation complete after 5s [id=testserver11]
    module.loadbalancingservices.citrixadc_service.tf_service["testserver12"]: Creating...
    module.loadbalancingservices.citrixadc_service.tf_service["testserver11"]: Creating...
    module.sslcertkeyname.citrixadc_systemfile.sslkey: Creation complete after 5s [id=/flash/nsconfig/ssl/terracert.key]
    module.sslcertkeyname.citrixadc_sslcertkey.tf_certkeypair: Creating...
    module.lbvserverssl.citrixadc_lbvserver.tf_lbvserverssl: Still creating... [10s elapsed]
    citrixadc_lbvserver.tf_lbvserverhttp: Still creating... [10s elapsed]
    module.ciphergroupname.citrixadc_sslcipher.tf_sslcipher: Still creating... [10s elapsed]
    module.vsciphergroupname.citrixadc_sslcipher.tf_sslcipher: Still creating... [10s elapsed]
    module.loadbalancingservices.citrixadc_service.tf_service["testserver12"]: Creation complete after 6s [id=testserver12-18082]
    module.sslcertkeyname.citrixadc_sslcertkey.tf_certkeypair: Creation complete after 6s [id=terracert]
    citrixadc_lbvserver.tf_lbvserverhttp: Creation complete after 12s [id=example.com:80]
    module.loadbalancingservices.citrixadc_service.tf_service["testserver11"]: Creation complete after 10s [id=testserver11-18082]
    module.lbvserverssl.citrixadc_lbvserver.tf_lbvserverssl: Creation complete after 16s [id=example.com:443]
    citrixadc_lbvserver_service_binding.tf_binding["testserver12"]: Creating...
    citrixadc_lbvserver_service_binding.tf_binding["testserver11"]: Creating...
    module.lbvserverssl.citrixadc_sslvserver.tf_sslvserver: Creating...
    citrixadc_lbvserver_service_binding.tf_binding["testserver11"]: Creation complete after 3s [id=example.com:443,testserver11-18082]
    citrixadc_lbvserver_service_binding.tf_binding["testserver12"]: Creation complete after 3s [id=example.com:443,testserver12-18082]
    module.lbvserverssl.citrixadc_sslvserver.tf_sslvserver: Creation complete after 3s [id=example.com:443]
    citrixadc_sslvserver_sslcertkey_binding.cert_binding: Creating...
    module.ciphergroupname.citrixadc_sslcipher.tf_sslcipher: Still creating... [20s elapsed]
    module.vsciphergroupname.citrixadc_sslcipher.tf_sslcipher: Still creating... [20s elapsed]
    citrixadc_sslvserver_sslcertkey_binding.cert_binding: Creation complete after 3s [id=example.com:443,terracert]
    module.vsciphergroupname.citrixadc_sslcipher.tf_sslcipher: Creation complete after 22s [id=External]
    citrixadc_sslvserver_sslciphersuite_binding.tf_sslvserver_sslciphersuite_binding: Creating...
    citrixadc_sslvserver_sslciphersuite_binding.tf_sslvserver_sslciphersuite_binding: Creation complete after 1s [id=example.com:443,External]
    module.ciphergroupname.citrixadc_sslcipher.tf_sslcipher: Creation complete after 23s [id=Internal]
    citrixadc_sslservice_sslciphersuite_binding.tf_sslservice_sslcipher_binding["testserver12"]: Creating...
    citrixadc_sslservice_sslciphersuite_binding.tf_sslservice_sslcipher_binding["testserver11"]: Creating...
    citrixadc_sslservice_sslciphersuite_binding.tf_sslservice_sslcipher_binding["testserver11"]: Creation complete after 1s [id=testserver11-18082,Internal]
    citrixadc_sslservice_sslciphersuite_binding.tf_sslservice_sslcipher_binding["testserver12"]: Creation complete after 1s [id=testserver12-18082,Internal]
    Apply complete! Resources: 18 added, 0 changed, 0 destroyed.
    lbservices = [
    showsvcciphergroup = "Internal"
    showvsciphergroup = "External"
    Other things to note
    The child shared modules as mentioned can be run as individual module. The output value of it can be called/referenced in root/parent module. Most of organization uses entities which are shared between multiple entity e.g. ciphergroup. During terraform destroy the shared module configuration should not get destroyed if that is shared with multiple entities, to avoid this type of false positive, run the shared child module individually and pass the value in root module.

  • Create New...