Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include Microsoft, Azure, DotNet, AspNet and Xamarin.
If you believe you have found a security vulnerability in any Microsoft-owned repository that meets Microsoft’s definition of a security vulnerability, please report it to us as described below.
Please do not report security vulnerabilities through public GitHub issues.
Instead, please report them to the Microsoft Security Response Center (MSRC) at https://msrc.microsoft.com/create-report.
If you prefer to submit without logging in, send email to secure@microsoft.com. If possible, encrypt your message with our PGP key; please download it from the Microsoft Security Response Center PGP Key page.
You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at microsoft.com/msrc.
Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
This information will help us triage your report more quickly.
If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our Microsoft Bug Bounty Program page for more details about our active programs.
We prefer all communications to be in English.
Microsoft follows the principle of Coordinated Vulnerability Disclosure.
The project maintainers commit to remediating confirmed vulnerabilities based on severity:
| Severity | Remediation Target |
|---|---|
| Critical and High | 60 days |
| Medium | 90 days |
Remediation timelines begin when the vulnerability is confirmed and may involve a code fix, configuration change, dependency update, or documented mitigation. Tracking is done through GitHub Security Advisories or GitHub issues. If a fix requires more time, the maintainers will publish a mitigation or workaround within the target window and document the extended timeline.
This project maintains a threat model and assurance case covering STRIDE analysis, trust boundaries, and risk acceptances for the reference architecture.
[!IMPORTANT] This reference architecture is provided under the MIT License and offered “AS IS” without warranty of any kind. The security guidance in this document is informational only and does not constitute professional security advice. You are solely responsible for evaluating the security of your own deployment, including all configuration, operational practices, and compliance requirements. The project maintainers accept no liability for security incidents arising from the use of this architecture.
This reference architecture includes certain security configurations as a starting point. These configurations are not a substitute for a security assessment tailored to your environment.
| Included Configuration | Description | Your Responsibility |
|---|---|---|
| Private AKS cluster option | Enabled by default via Terraform variable | Evaluate whether private mode meets your network requirements |
| Managed identities | User-assigned identity for AKS | Review identity permissions and scope for your workloads |
| Azure Key Vault integration | Key Vault CSI driver configured | Manage secret lifecycle, rotation, and access policies |
| Kubernetes network policies | Azure CNI with network policy support enabled | Define and maintain policies appropriate for your workloads |
| Workload identity | Federated credential configuration for OSMO | Verify audience restrictions and token scoping for your environment |
| Not Included | Why | Where to Start |
|---|---|---|
| Production hardening | Requirements vary by organization and compliance framework | AKS baseline architecture |
| Compliance certification | Compliance is organization-specific and requires formal assessment | Azure compliance documentation |
| Web Application Firewall | WAF configuration depends on ingress patterns and threat model | Azure WAF documentation |
| DDoS protection | DDoS requirements depend on public exposure and SLA needs | Azure DDoS Protection |
| Penetration testing | Pen testing is an operational responsibility | Azure penetration testing rules |
| Remote Terraform state | State backend choice depends on team size and workflow | Terraform Azure backend |
| Secret rotation automation | Rotation schedules are organization-specific | Key Vault rotation |
| Audit logging configuration | Logging requirements vary by compliance framework | Azure Monitor |
You are responsible for all security decisions in your deployment:
Refer to official Azure security documentation for authoritative, current guidance.
For comprehensive security documentation including threat models and deployment security guidance, see Security Documentation.