Categories
Tech

Salt SDDC Modules – Manage VMC Security Groups and Rules

After two SDDC Extension Modules introductory posts about getting started and state files, in this post I cover something more juicy from my point of view: managing VMware Cloud on AWS (VMC) Security Groups and Security Rules. Of course as a pre-requisite, in addition to having Salt Master with SDDC extensions modules, you need to have access to a VMC SDDC. For this lab activity I was supported by Matteo Concilio who is a true VMC and VCF expert and a super nice person!

In order to manage VMC SDDC Networking & Security configuration we will leverage modules named vmc_security_group and vmc_security_rules, but to collect all the required info we will also use module named vmc_sddc.

Required information and how to collect it

These are the information you need to collect before creating your state files.

refresh_key

This is your VMware CSP API Token, here is the doc page “How Do I Generate API Tokens” for VMware Cloud Console. The grants I used for this use case are showed in the picture below, they might be a bit beyond the minimum required.

authorization_host

This is a constant value console.cloud.vmware.com

org_id

This is the Organization ID of the SDDC instance to be managed. On the Cloud Services Console toolbar, click your username and copy the Organization ID. There is little icon button that helps you in this.

hostname

This is the hostname of NSX-T manager of your SDDC. In order to obtain this info you can use the get function from the vmc_sddc module as follows:

salt-call vmc_sddc.get hostname=vmc.vmware.com refresh_key=<Your_CSP_API_Token> authorization_host=console.cloud.vmware.com org_id=<Your_Org_ID> verify_ssl=False cert=None > ~/sddcs.yaml

In the ~/sddcs.yaml file look for the parameter named nsx_reverse_proxy_url and this would be something like https://nsx-11-22-33-44.rp.vmwarevmc.com/vmc/reverse-proxy/api/ here you just need to save the FQDN of that URL, nsx-11-22-33-44.rp.vmwarevmc.com in the example.

It is a good practice to store this sensitive data in a Pillar, so you can add a new Pillar file ~/salt/srv/pillar/smea_vmc_conf.sls with the following structure:

nsx_hostname: <Your_NSX_Hostname>
refresh_key: <Your_Refresh_Key>
authorization_host: console.cloud.vmware.com
org_id: <Your_Org_ID>
sddc_id: <Your_SDDC_ID>

Then you need to modify the Pillar Top file by adding the newly created pillar file as follows:

base:
  master_minion:
    - my_vsphere_conf
    - semea_vmc_conf

To make sure the new Pillar data is assigned to your minion you can run the following command:

salt-call pillar.items

The output should include both my_vpshere_conf and semea_vmc_conf contents.

Now we have the basic info required to authenticate to our SDDC instance.

State Files

The first state file will be used to create a new Security Group, please note that we could have all the configuration in a single state file. Add ~/salt/srv/salt/group_create.sls State file with the content reported in the snippet below. You may need to use a different path if you didn’t configure your Master as per instructions from my Salt SDDC Modules – Getting Started post.

#Create a new Security Group
group_present:
  module.run:
    - name: vmc_security_groups.create
    - hostname: {{ pillar['nsx_hostname'] }} 
    - refresh_key: {{ pillar['refresh_key'] }} 
    - authorization_host: {{ pillar['authorization_host'] }} 
    - org_id: {{ pillar['org_id'] }} 
    - sddc_id: {{ pillar['sddc_id'] }} 
    - domain_id: cgw 
    - verify_ssl: False 
    - cert: None 
    - security_group_id: paolo

Relevant information in the state above:

  • domain_id: this allows you to choose whether create the new group under the Management Gateway or the Compute Gateway. Possible values: mgw, cgw. In this case we are using cgw that clearly stands for the Compute Gateway
  • security_group_id: this lets you set the name and the id (to be the same) of your new Security Group

Please, note that a good number of other optional parameters are available for this function.

The second State file creates a Security Rule. Add ~/salt/srv/salt/rule_create.sls State file with the content reported below:

#Create a new Security Rule
ensure_security_rule:
  vmc_security_rules.present:
    - hostname: {{ pillar['nsx_hostname'] }} 
    - refresh_key: {{ pillar['refresh_key'] }} 
    - authorization_host: {{ pillar['authorization_host'] }} 
    - org_id: {{ pillar['org_id'] }} 
    - sddc_id: {{ pillar['sddc_id'] }} 
    - verify_ssl: False 
    - cert: None
    - rule_id: paolo_rule 
    - domain_id: cgw 
    - source_groups: ["/infra/domains/cgw/groups/paolo"] 
    - destination_groups: ["ANY"] 
    - services: ["/infra/services/SSH"] 
    - action: ALLOW 
    - logged: true

Relevant information in the state above:

  • rule_id: this lets you set the name and the id (to be the same) of your new Security Rule
  • source_groups: this lets you provide a list of Security Groups as source in the rule. IMPORTANT: we need to provide Security Group as a path as duplicated Security Group names may exist for groups under different domains. Along with paths we support IPv4 and IPv6 Address. IP Address can be in one of the format: CIDR, IP Address, and Range of IP Address. In order to specify all groups, use the constant “ANY”
  • destination_groups: this lets you provide a list of Security Groups as destination in the rule. See above source_group for format and options
  • services: this lets you provide a list of Services in the rule. IMPORTANT: we need to provide Services as a path as we did for groups in source and destination. In order to specify all Services, use the constant “ANY”. This is case insensitive. If “ANY” is used, it should be the ONLY element in the services array
  • action: this lets you specify the action for the rule. Possible values for domain_id=cgw are: ALLOW, DROP, REJECT. While, the only possible value for domain_id=mgw is ALLOW;
  • logged: this is a flag to let you enable packet logging. Default is false (disabled)

Please, note that also for this function many other optional parameters are available.

Note: you have two options to collect the correct path for a Security Group:

  1. List all the groups in a domain using the get function from the vmc_security_groups Execution Module
  2. From the VMC UI select your SDDC, go to the “Networking & Security” tab, click “Inventory>Groups” in the left tree and then click on the three dots icon close to your group and select “Copy Path to Clipboard”

To my knowledge, the only way to collect the path of a Service is: from the VMC UI select your SDDC, go to the “Networking & Security” tab and in the left tree click “Inventory>Services” and then click on the three dots icon close to your service and select “Copy Path to Clipboard”.

Let’s use these State files to create group and rule respectively:

salt-call state.apply group_create

You may want to first run this State file in test mode as I did in the screenshot below. To do that you just need to add the test=True option in your command.

The new Security Group is created under Compute Gateway, there is now a silly group named “paolo” in my console.

Let’s create a rule that consumes the newly created group:

salt-call state.apply rule_create

When I run this state I got an error message that however did not prevented the rule to be created. Honestly I didn’t bother to further troubleshoot it.

The new Security Rule is created under Compute Gateway, there is now a very creative rule named “paolo_rule” in my console.

Here after I am also sharing a State file to delete the newly created objects. I think it is now obvious how to use this.

#Delete the Security Rule named paolo_rule
security_rule_delete:
  vmc_security_rules.absent:
    - hostname: {{ pillar['nsx_hostname'] }} 
    - refresh_key: {{ pillar['refresh_key'] }} 
    - authorization_host: {{ pillar['authorization_host'] }} 
    - org_id: {{ pillar['org_id'] }} 
    - sddc_id: {{ pillar['sddc_id'] }} 
    - verify_ssl: False 
    - cert: None
    - rule_id: paolo_rule 
    - domain_id: cgw

#Delete the Security Group named paolo
group_delete:
  module.run:
    - name: vmc_security_groups.delete
    - hostname: {{ pillar['nsx_hostname'] }} 
    - refresh_key: {{ pillar['refresh_key'] }} 
    - authorization_host: {{ pillar['authorization_host'] }} 
    - org_id: {{ pillar['org_id'] }} 
    - sddc_id: {{ pillar['sddc_id'] }} 
    - domain_id: cgw 
    - verify_ssl: False 
    - cert: None 
    - security_group_id: paolo
    - requires:
      - security_rule_delete

You can use this as a starting point for automating your VMC SDDC’s security rules management activities. I hop it helps!