Skip to content

Farmer Azure security capabilities #1233

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.

Sign up for GitHub

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

Open
Thorium wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Farmer Azure security capabilities #1233

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
93 changes: 91 additions & 2 deletions docs/content/api-overview/resources/container-registry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,11 @@ The Container Registry builder is used to create Azure Container Registry (ACR)
|-|-|
| name | Sets the name of the Container Registry instance. |
| sku | Sets the SKU of the instance. Defaults to Basic. |
| enable_admin_user | The value that indicates whether the admin user is enabled. |
| enable_admin_user | Enables the admin user (not recommended for production). |
| enable_public_network_access | Explicitly enables public network access. |
| disable_public_network_access | Disables public network access (Premium SKU only, recommended for security). |
| add_ip_rule | Adds an IP address or CIDR range to the allow list (Premium SKU only). |
| add_ip_rules | Adds multiple IP addresses or CIDR ranges to the allow list (Premium SKU only). |

#### Configuration Members

Expand All @@ -25,7 +29,7 @@ The Container Registry builder is used to create Azure Container Registry (ACR)
| Password2 | Gets the ARM expression path to the second admin password of this container registry if the admin user was enabled. |
| Username | Gets the ARM expression path to the admin username of this container registry if the admin user was enabled. |

#### Example
#### Basic Example
```fsharp
open Farmer
open Farmer.Builders
Expand All @@ -36,3 +40,88 @@ let myRegistry = containerRegistry {
enable_admin_user
}
```

#### Secure Example with Network Restrictions (Premium SKU)
```fsharp
open Farmer
open Farmer.Builders
open Farmer.ContainerRegistry

let secureRegistry = containerRegistry {
name "mySecureRegistry"
sku Premium
// Disable public network access - use private endpoints only
disable_public_network_access
}

let restrictedRegistry = containerRegistry {
name "myRestrictedRegistry"
sku Premium
// Allow access only from specific IP addresses/ranges
add_ip_rules [
"203.0.113.0/24" // Corporate network
"198.51.100.5" // Build server
]
}
```

#### Security Best Practices

1. **Disable Admin User**: The admin user provides a single account with full access to the registry. For production, use Azure AD authentication with managed identities instead.

2. **Use Premium SKU for Production**: Only the Premium SKU supports:
- Network restrictions (IP rules and private endpoints)
- Disabling public network access
- Content trust and image signing
- Customer-managed keys

3. **Restrict Network Access**: Use one of these strategies:
- **Disable Public Access**: Use `disable_public_network_access` and access only through private endpoints (most secure)
- **IP Restrictions**: Use `add_ip_rules` to limit access to known IP addresses

4. **Use Managed Identities**: Instead of admin credentials, authenticate using Azure managed identities from services like AKS, Azure DevOps, or GitHub Actions.

#### Network Security Notes

- **IP Rules require Premium SKU**: Network restrictions are only available with the Premium tier
- **Default Deny**: When you add IP rules, all other IPs are denied by default
- **CIDR Notation**: IP rules support both individual IPs (`203.0.113.5`) and CIDR ranges (`203.0.113.0/24`)
- **Private Endpoints**: For complete isolation, use `disable_public_network_access` and connect via private endpoints

#### Cost Considerations

Azure Container Registry pricing varies significantly by SKU tier:

| SKU | Approx. Monthly Cost* | Storage (Included) | Network Features |
|-----|----------------------|-------------------|------------------|
| **Basic** | ~$5 USD | 10 GB | Public access only |
| **Standard** | ~$20 USD | 100 GB | Public access only |
| **Premium** | ~$500 USD | 500 GB | IP rules, private endpoints, geo-replication |

*Approximate costs as of 2025. Additional charges apply for:
- Storage beyond included amounts: ~$0.10/GB per day
- Build tasks and image pulls
- Geo-replication (Premium only)
- Data egress

**Cost Optimization Tips:**
1. **Start with Basic**: Use Basic SKU for development/testing environments
2. **Standard for Production**: Standard SKU provides better performance and storage for most production workloads
3. **Premium When Needed**: Only upgrade to Premium when you specifically need:
- Network restrictions (IP rules, private endpoints)
- Geo-replication for global deployments
- Enhanced security features (content trust, customer-managed keys)
4. **Clean Up Old Images**: Regularly delete unused images to minimize storage costs
5. **Use Retention Policies**: Premium SKU supports automated image cleanup policies

**Security vs. Cost Tradeoff:**
- Network restrictions (IP rules, private endpoints) require Premium SKU (~$500/month)
- For sensitive workloads, this cost is justified by the enhanced security
- For less sensitive workloads, consider Basic/Standard with Azure AD authentication and proper RBAC

#### Compliance

Container Registry with network restrictions helps meet security requirements from:
- **NIST 800-53**: AC-3 (Access Enforcement), SC-7 (Boundary Protection)
- **CIS Benchmarks**: 6.10 (Restrict container registry network access)
- **SOC 2**: CC6.6 (Logical and Physical Access Controls)
101 changes: 101 additions & 0 deletions docs/content/api-overview/resources/ddos-protection-plan.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,101 @@
---
title: "DDoS Protection Plan"
date: 2025-11-08
chapter: false
weight: 14
---

#### Overview
The DDoS Protection Plan builder creates Azure DDoS Protection Plans that provide enhanced DDoS mitigation capabilities for virtual networks.

* DDoS Protection Plan (`Microsoft.Network/ddosProtectionPlans`)

> DDoS Protection Plans provide always-on traffic monitoring and automatic mitigation of DDoS attacks. They can be shared across multiple virtual networks in the same subscription or across subscriptions in the same Azure AD tenant, providing cost-effective protection at scale.

#### Builder Keywords

| Keyword | Purpose |
|-|-|
| name | Sets the name of the DDoS Protection Plan |
| add_tag | Adds a tag to the DDoS Protection Plan |
| add_tags | Adds multiple tags to the DDoS Protection Plan |

#### Example

```fsharp
open Farmer
open Farmer.Builders

let myDdosPlan = ddosProtectionPlan {
name "my-ddos-protection-plan"
add_tags [
"environment", "production"
"cost-center", "security"
]
}

let deployment = arm {
location Location.EastUS
add_resource myDdosPlan
}
```

#### Cost Considerations

DDoS Protection Plan is a premium service with a fixed monthly cost (~$3,000 USD/month) plus data transfer charges. However, a single DDoS Protection Plan can be:

* Shared across all virtual networks in a subscription
* Shared across subscriptions in the same Azure AD tenant

This makes it cost-effective to deploy a single DDoS Protection Plan at the tenant or management group level and share it across all virtual networks.

#### Best Practices

1. **Centralized Deployment**: Create one DDoS Protection Plan per tenant and share it across all virtual networks
2. **Tagging**: Use tags to track the cost center and ownership
3. **Virtual Network Association**: After creating a DDoS Protection Plan, associate it with virtual networks using the `link_to_ddos_protection_plan` operation on virtual networks

#### Linking to Virtual Networks

Once a DDoS Protection Plan is created, it must be linked to virtual networks to provide protection:

```fsharp
let ddosPlan = ddosProtectionPlan {
name "shared-ddos-plan"
}

let vnet = vnet {
name "my-vnet"
add_address_spaces [ "10.0.0.0/16" ]
link_to_ddos_protection_plan ddosPlan
}

let deployment = arm {
location Location.EastUS
add_resources [ ddosPlan; vnet ]
}
```

> Note: The `link_to_ddos_protection_plan` operation for virtual networks will be available in a future Farmer release.

#### Security Benefits

DDoS Protection Plan provides:

* **Always-on traffic monitoring**: Continuous monitoring of application traffic patterns
* **Automatic attack mitigation**: Instant attack detection and mitigation without user intervention
* **Attack analytics**: Detailed metrics and diagnostics during and after attacks
* **Adaptive tuning**: Machine learning-based traffic profiling for more accurate detection
* **Protection for Azure resources**: Covers public IP addresses, Application Gateways, and Azure Load Balancers
* **DDoS rapid response support**: Access to DDoS experts during an active attack
* **Cost protection**: Service credits for scale-out costs during documented attacks

#### Compliance

DDoS Protection Plans help meet compliance requirements from security frameworks including:

* **NIST Cybersecurity Framework**: SC-5 (Denial of Service Protection)
* **ISO 27001**: A.14.1.2 (Securing application services)
* **PCI DSS**: Requirement 5 (Protect all systems against malware and regularly update anti-virus software)
* **SOC 2**: CC7.2 (System monitoring)

Loading
Loading