-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Add Azure infrastructure skills (Landing Zone, WAF Review, Implementa… #603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,78 @@ | ||
| --- | ||
| name: Azure Infrastructure Architect | ||
| description: "Expert Azure infrastructure architect that designs, reviews, and implements Azure solutions following Well-Architected Framework and Cloud Adoption Framework best practices." | ||
| tools: | ||
| - codebase | ||
| - runCommand | ||
| - editFiles | ||
| --- | ||
|
|
||
| You are an expert Azure Infrastructure Architect with deep knowledge of: | ||
| - Azure Landing Zones and Cloud Adoption Framework (CAF) | ||
| - Well-Architected Framework (WAF) - all 5 pillars | ||
| - Infrastructure as Code (Bicep, Terraform, Azure Verified Modules) | ||
| - CI/CD pipelines for Azure deployments | ||
|
|
||
| ## Your Capabilities | ||
|
|
||
| ### 1. Design Azure Landing Zones | ||
| When asked to design infrastructure: | ||
| - Propose management group hierarchy | ||
| - Design subscription organization (platform vs. landing zones) | ||
| - Recommend networking topology (hub-spoke or Virtual WAN) | ||
| - Define identity and governance strategy | ||
|
|
||
| ### 2. Review Architectures | ||
| When asked to review: | ||
| - Assess against all 5 WAF pillars (Reliability, Security, Cost, Operations, Performance) | ||
| - Classify findings by severity (Critical, High, Medium, Low) | ||
| - Provide specific remediation recommendations | ||
| - Prioritize improvements | ||
|
|
||
| ### 3. Implement Infrastructure | ||
| When asked to implement or deploy: | ||
| - Generate Bicep code (preferred) or Terraform | ||
| - Use Azure Verified Modules (AVM) where available | ||
| - Follow naming conventions and security best practices | ||
| - Create deployment pipelines (GitHub Actions or Azure DevOps) | ||
|
|
||
| ### 4. Deploy Applications | ||
| When asked to deploy an application: | ||
| 1. **Analyze** the application (language, framework, dependencies) | ||
| 2. **Design** the target architecture | ||
| 3. **Generate** IaC for required resources | ||
| 4. **Create** CI/CD pipeline | ||
| 5. **Provide** deployment commands | ||
|
|
||
| ## Security Requirements (Non-Negotiable) | ||
| - Never hardcode credentials or secrets | ||
| - Always use managed identities for service-to-service auth | ||
| - Enable Key Vault with purge protection | ||
| - Use private endpoints for PaaS services | ||
| - Enforce TLS 1.2 minimum | ||
| - Disable storage/Cosmos key access (use RBAC) | ||
|
|
||
| ## Deployment Workflow | ||
| Always follow this pattern: | ||
| 1. Preview changes with `az deployment group what-if` | ||
| 2. Validate before deploying | ||
| 3. Deploy with explicit resource group targeting | ||
| 4. Provide Azure Portal links after deployment | ||
|
|
||
| ## Response Style | ||
| - Be concise and actionable | ||
| - Provide code, not just descriptions | ||
| - Use tables for comparisons | ||
| - Include commands that can be run directly | ||
| - Warn about security risks prominently | ||
|
|
||
| ## Example Interaction | ||
|
|
||
| **User**: "Deploy a Python Flask API with PostgreSQL to Azure" | ||
|
|
||
| **Your approach**: | ||
| 1. Confirm requirements (region, environment, scale needs) | ||
| 2. Generate architecture: App Service + Azure Database for PostgreSQL + Key Vault | ||
| 3. Create Bicep files with proper security (managed identity, private endpoints) | ||
| 4. Create GitHub Actions workflow | ||
| 5. Provide step-by-step deployment commands |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,202 @@ | ||
| --- | ||
| name: azure-infra-patterns | ||
| description: | | ||
| Implementation patterns for Azure infrastructure using Bicep, Terraform, and Azure Verified Modules. | ||
| Use when: | ||
| (1) Implementing infrastructure-as-code for Azure resources | ||
| (2) Choosing between Bicep and Terraform for a project | ||
| (3) Using Azure Verified Modules (AVM) or Azure Landing Zone (ALZ) modules | ||
| (4) Setting up CI/CD pipelines for infrastructure deployment | ||
| (5) Converting architecture designs to deployable code | ||
| (6) Implementing security-hardened resource configurations | ||
| Triggers: Bicep, Terraform, IaC, infrastructure code, AVM, Azure Verified Modules, | ||
| ALZ, Azure Landing Zones, ARM template, HCL, deployment | ||
| --- | ||
|
Comment on lines
+1
to
+14
|
||
|
|
||
| # Azure Infrastructure Implementation Patterns | ||
|
|
||
| Transform architecture designs into secure, repeatable infrastructure code. | ||
|
|
||
| ## Tool Selection | ||
|
|
||
| | Factor | Bicep | Terraform | | ||
| |--------|-------|-----------| | ||
| | Azure-native | ✅ First-class | Good (AzureRM/AzAPI) | | ||
| | Multi-cloud | ❌ | ✅ | | ||
| | State management | Azure handles | Backend required | | ||
| | Module ecosystem | AVM | AVM + Registry | | ||
| | Learning curve | Lower | Medium | | ||
| | Team skills | Azure-focused | Platform engineers | | ||
|
|
||
| **Default choice**: Bicep for Azure-only projects, Terraform for multi-cloud or existing Terraform expertise. | ||
|
|
||
| ## Project Structure | ||
|
|
||
| ### Bicep Projects | ||
| ``` | ||
| project/ | ||
| ├── infra/ | ||
| │ ├── main.bicep # Entry point | ||
| │ ├── main.bicepparam # Parameters | ||
| │ ├── modules/ # Custom modules | ||
| │ │ ├── networking/ | ||
| │ │ ├── compute/ | ||
| │ │ └── data/ | ||
| │ └── environments/ | ||
| │ ├── dev.bicepparam | ||
| │ └── prod.bicepparam | ||
| ``` | ||
|
|
||
| ### Terraform Projects | ||
| ``` | ||
| project/ | ||
| ├── terraform/ | ||
| │ ├── main.tf # Root module | ||
| │ ├── variables.tf # Input variables | ||
| │ ├── outputs.tf # Outputs | ||
| │ ├── versions.tf # Provider constraints | ||
| │ ├── backend.tf # State backend | ||
| │ └── modules/ | ||
| │ ├── networking/ | ||
| │ └── compute/ | ||
| ``` | ||
|
|
||
| ## Azure Verified Modules (AVM) | ||
|
|
||
| Prefer AVM over custom implementations for production workloads. | ||
|
|
||
| ### Bicep AVM Usage | ||
| ```bicep | ||
| module storageAccount 'br/public:avm/res/storage/storage-account:0.9.0' = { | ||
| name: 'storage-deployment' | ||
| params: { | ||
| name: storageAccountName | ||
| location: location | ||
| skuName: 'Standard_LRS' | ||
| kind: 'StorageV2' | ||
| publicNetworkAccess: 'Disabled' | ||
| networkAcls: { | ||
| defaultAction: 'Deny' | ||
| } | ||
| } | ||
| } | ||
|
|
||
| module keyVault 'br/public:avm/res/key-vault/vault:0.6.0' = { | ||
| name: 'keyvault-deployment' | ||
| params: { | ||
| name: keyVaultName | ||
| location: location | ||
| enableRbacAuthorization: true | ||
| enablePurgeProtection: true | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### Terraform AVM Usage | ||
| ```hcl | ||
| module "storage_account" { | ||
| source = "Azure/avm-res-storage-storageaccount/azurerm" | ||
| version = "0.1.0" | ||
|
|
||
| name = var.storage_account_name | ||
| resource_group_name = azurerm_resource_group.main.name | ||
| location = var.location | ||
|
|
||
| public_network_access_enabled = false | ||
| network_rules = { | ||
| default_action = "Deny" | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Security Requirements (Non-Negotiable) | ||
|
|
||
| Every resource must implement: | ||
|
|
||
| | Requirement | Implementation | | ||
| |-------------|----------------| | ||
| | No hardcoded credentials | Key Vault references | | ||
| | Managed identities | System or user-assigned | | ||
| | Encryption at rest | Platform or CMK | | ||
| | TLS 1.2 minimum | `minTlsVersion: 'TLS1_2'` | | ||
| | Private networking | Private endpoints | | ||
| | RBAC authorization | `enableRbacAuthorization: true` | | ||
|
|
||
| ### Critical Security Settings | ||
| ```bicep | ||
| // Storage - NEVER allow public access | ||
| resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = { | ||
| properties: { | ||
| allowBlobPublicAccess: false | ||
| allowSharedKeyAccess: false // Use RBAC | ||
| minimumTlsVersion: 'TLS1_2' | ||
| supportsHttpsTrafficOnly: true | ||
| } | ||
| } | ||
|
|
||
| // Key Vault - NEVER disable purge protection | ||
| resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = { | ||
| properties: { | ||
| enablePurgeProtection: true // NEVER false | ||
| enableRbacAuthorization: true | ||
| publicNetworkAccess: 'Disabled' | ||
| } | ||
| } | ||
|
|
||
| // Container Registry - NEVER enable anonymous pull | ||
| resource acr 'Microsoft.ContainerRegistry/registries@2023-07-01' = { | ||
| properties: { | ||
| anonymousPullEnabled: false | ||
| adminUserEnabled: false | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Deployment Workflow | ||
|
|
||
| ### Bicep Deployment | ||
| ```bash | ||
| # 1. Validate | ||
| az bicep build --file infra/main.bicep | ||
|
|
||
| # 2. Preview (ALWAYS before deploy) | ||
| az deployment group what-if \ | ||
| --resource-group rg-prod \ | ||
| --template-file infra/main.bicep \ | ||
| --parameters @infra/environments/prod.bicepparam | ||
|
|
||
| # 3. Deploy | ||
| az deployment group create \ | ||
| --resource-group rg-prod \ | ||
| --template-file infra/main.bicep \ | ||
| --parameters @infra/environments/prod.bicepparam | ||
| ``` | ||
|
|
||
| ### Terraform Deployment | ||
| ```bash | ||
| # 1. Format and validate | ||
| terraform fmt -recursive | ||
| terraform validate | ||
|
|
||
| # 2. Plan (ALWAYS before apply) | ||
| terraform plan -out=tfplan | ||
|
|
||
| # 3. Apply | ||
| terraform apply tfplan | ||
| ``` | ||
|
|
||
| ### Azure Developer CLI (azd) | ||
| ```bash | ||
| # Preview | ||
| azd provision --preview | ||
|
|
||
| # Deploy infrastructure and application | ||
| azd up | ||
| ``` | ||
|
|
||
| ## References | ||
|
|
||
| - **Bicep patterns**: See [references/bicep.md](references/bicep.md) | ||
| - **Terraform patterns**: See [references/terraform.md](references/terraform.md) | ||
| - **CI/CD pipelines**: See [references/cicd.md](references/cicd.md) | ||
| - **Naming conventions**: See [references/naming.md](references/naming.md) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
descriptionfield in the front matter is using a block scalar (|) instead of a single-quoted string, which diverges from the SKILL.md conventions used elsewhere in the repo. To keep SKILL metadata consistent, consider switching this to a single-quoteddescriptionvalue on one line.