Security

Acmebot relies on Azure identity, Key Vault, DNS provider credentials, and dashboard authentication. This page summarizes the security model and recommended operational boundaries.

Dashboard Authentication

The Function App serves the dashboard and API endpoints with anonymous trigger authorization, but the application code requires an authenticated user.

Configure App Service Authentication and require sign-in before requests reach the app. Microsoft Entra ID is the typical provider for Azure-hosted deployments.

The dashboard and every API endpoint return 401 unless App Service Authentication is enabled (WEBSITE_AUTH_ENABLED=true) and the caller is authenticated. Supplying identity headers alone does not satisfy this requirement when authentication is disabled.

The HTTP triggers are configured with anonymous trigger authorization so App Service Authentication can provide the authenticated user principal to the application. Do not rely on a Functions host key as the only protection for the dashboard or API in v5 deployments.

Response Headers

All responses include X-Frame-Options: DENY, Content-Security-Policy: frame-ancestors 'none', and X-Content-Type-Options: nosniff, so the dashboard cannot be embedded in another site's frame for clickjacking.

App Roles

By default, any authenticated dashboard user can issue, manually renew, and revoke certificates. To require app roles for sensitive operations, set:

Acmebot__RequireAppRoles=true

Then assign these roles in the application registration:

Role	Allows
Acmebot.IssueCertificate	Issue and manually renew certificates.
Acmebot.RevokeCertificate	Revoke certificates.

Listing certificates and DNS zones still requires authentication.

App Role Setup Checklist

1. Add the roles to the Microsoft Entra application registration used by App Service Authentication.
2. Assign the roles to users, groups, or service principals that should operate Acmebot.
3. Set Acmebot__RequireAppRoles=true on the Function App.
4. Restart the Function App so the new configuration value is applied.
5. Confirm a caller without the role receives 403 for issue, manual renewal, or revoke operations.

Managed Identity

Use managed identity for Azure resource access and cross-cloud federation. By default, Acmebot uses the app-wide managed identity. Azure DNS, Azure Private DNS, Route 53 web identity federation, and Google Cloud DNS workload identity federation can use provider-specific user-assigned managed identity client IDs. If no client ID is configured, Azure SDK clients use the Function App system-assigned managed identity.

Recommended scopes:

Resource	Permission
Key Vault	Key Vault Certificates Officer or equivalent certificate permissions.
Azure DNS zone	DNS Zone Contributor or a narrower custom role.
Azure Private DNS zone	Private DNS Zone Contributor or a narrower custom role.
Route 53 IAM role	Trust policy that allows the selected managed identity web identity token to assume the role.
Google Cloud service account	Workload identity principal binding that allows the selected managed identity token to impersonate the service account.

Prefer assigning roles at the individual zone or vault scope rather than subscription scope.

DNS Provider Credentials

External DNS provider credentials are stored as Function App app settings. Treat them as operational secrets.

The shared REST client does not follow HTTP redirects, including when a provider uses a custom signing handler. Configure the final API endpoint for providers with a configurable URL; a redirect response is treated as a failed provider request.

Recommendations:

• Use provider API tokens instead of account-wide credentials when available.
• Scope tokens to the zones Acmebot manages.
• Grant only zone read and DNS record edit permissions.
• Use App Service Key Vault references for secret values when your operations model supports it.
• Rotate credentials regularly.
• Restart the Function App after updating credentials.

Deployment Parameters

The deployment template accepts ACME credentials, DNS provider credentials, and additional app settings through secure object parameters. For additionalAppSettings, place the name/value pairs inside its settings array; see Additional App Settings for the format and migration from the previous array parameter.

Secure parameters prevent Azure Resource Manager from retaining those parameter values in deployment history. They do not encrypt local parameter files, remove values from shell history or external logs, or change who can read Function App app settings. Parent templates must also mark forwarded secret input parameters as secure. Prefer App Service Key Vault references when passing secret app settings.

Earlier template versions accepted additionalAppSettings as a non-secure array. If you passed credentials or signed webhook URLs directly through that parameter, treat the corresponding deployment history as containing secrets. Rotate those credentials or webhook URLs and remove the affected deployment history according to your retention policy. Updating the template does not remove values from earlier deployments or copies of their logs.

Key Vault

Acmebot stores private keys in Key Vault. It creates certificate operations and merges the issued public certificate chain into the pending operation.

Recommendations:

• Use Azure RBAC for new vaults.
• Restrict certificate read/export permissions to identities that need them.
• Keep purge protection and backup policies aligned with your organization's certificate recovery requirements.
• Use custom tags for ownership and cost tracking, but do not overwrite the reserved Acmebot tag.

Network Access

Acmebot needs outbound access to:

• The configured ACME directory.
• DNS provider APIs.
• Azure Resource Manager when using Azure DNS providers.
• Azure Key Vault.
• The configured webhook endpoint, if any.
• DNS resolvers used for challenge verification.

When using private networking or restricted outbound access, allow these dependencies explicitly.

Webhooks

Webhook URLs are secrets because they often include credentials or signed tokens. Store them in app settings and limit access to users who can manage Function App configuration.

Webhook delivery failures are logged but do not prevent certificate issuance from completing.