Building Blocks of Meraki as Code

This document is an important component of this guide, as it provides a foundational understanding of the structure of the code.

nac-meraki/
├── data/
├── .schema.yaml
├── .rules/
├── tests/
└── main.tf

Contains YAML configuration files used for Network as Code. This includes organization-wide settings, networks, appliances, switches, wireless settings etc.

The filenames are only examples below, you may be able to name them anything as long as it ends with .nac.yaml. .nac allows the VS Code to identify the YAML as a Network as Code Data Model and .yaml is the extension for YAML files.

Contents:

data/
├── organizations.nac.yaml
├── networks.nac.yaml
├── devices.nac.yaml
├── wireless_ssids.nac.yaml
├── ***.nac.yaml
├── ***.nac.yaml
├── ***.nac.yaml

• organizations.nac.yaml Define organization-level settings such as login security, policy objects, SNMP settings, etc.

• networks.nac.yaml Define networks, usually more than one and all network related settings such a floor plan, group_policies etc.

• devices.nac.yaml Define devices and their location, tags etc.

• wireless_ssids.nac.yaml Define wireless SSID’s and their settings

Primary Terraform configuration file. It defines infrastructure resources and modules for the NAC deployment.

Meraki as Code utilizes two distinct types of variables to achieve both security and flexibility in network deployments. Understanding these variable types is crucial for proper implementation and maintenance of your infrastructure.

Template variables use the $variable_name syntax and are used for configuration parameters that can vary between deployments but are not sensitive in nature. These variables are defined in the pods_variables.nac.yaml file and allow for site-specific customizations without modifying the core template logic.

Examples of Template Variables:

• Network addressing: ${vlan10_subnet}, ${vlan10_appliance_ip}
• Device naming: ${appliance_01_name}, ${access_switch_01_name}
• Network settings: ${time_zone}, ${network_notes}
• RADIUS servers: ${radius_server1_host}, ${radius_server1_port}
• Geographic coordinates: ${lat}, ${lng}, ${address}

How Template Variable Substitution Works:

Templates define placeholders using the variable syntax:

vlans:
  - vlan_id: 10
    name: 'Data'
    subnet: ${vlan10_subnet}
    appliance_ip: ${vlan10_appliance_ip}

Variables are then assigned values in the pods_variables.nac.yaml file:

variables:
  vlan10_subnet: 10.2.10.0/24
  vlan10_appliance_ip: 10.2.10.1

When the template is processed, the variables are substituted with their actual values:

vlans:
  - vlan_id: 10
    name: 'Data'
    subnet: 10.2.10.0/24
    appliance_ip: 10.2.10.1

These variables provide the flexibility to deploy standardized templates across multiple sites while accommodating site-specific requirements such as IP addressing schemes, device naming conventions, and local settings.

Environment variables use the !env syntax and are specifically designed for sensitive information that should never be stored in configuration files or committed to version control systems. This approach ensures that credentials, serial numbers, and other sensitive data remain secure.

Examples of Environment Variables:

• Device credentials: !env radius_server1_secret, !env radius_accounting_server1_secret
• Device serial numbers: !env Appliance, !env Switch1, !env AP
• Organization details: !env domain, !env org_name
• SNMP credentials: !env v3_auth_pass, !env v3_priv_pass

Usage Pattern:

# In template files
secret: !env radius_server1_secret
appliance_01_serial: !env Appliance

# In environment file (.env)
export radius_server1_secret="MySecretPassword"
export Appliance="Q2XX-XXXX-XXXX"

Environment variables are typically set in a .env file (which is excluded from version control) or through your deployment pipeline’s secret management system. This ensures that sensitive information is managed securely and separately from the infrastructure code.

Note on External Secret Management: For enterprise deployments, consider integrating with external secret management systems like CyberArk Conjur, HashiCorp Vault, Azure Key Vault, or AWS Secrets Manager instead of using local environment variables. These systems provide enhanced security features such as secret rotation, audit trails, fine-grained access controls, and centralized secret management across multiple environments. The !env syntax can be adapted to work with these systems through CI/CD pipeline integrations or custom secret retrieval mechanisms.

1. Template Variables: Use for non-sensitive configuration that varies between sites
2. Environment Variables: Use for all sensitive data including passwords, secrets, and device serial numbers
3. Version Control: Never commit .env files or files containing sensitive information
4. Documentation: Maintain clear documentation of required environment variables for each deployment