# Azure Key Vault Certificate Issuer Operations

Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.

## What people get wrong

- Assigning management-plane contributor access when only certificate data-plane lifecycle operations are needed.
- Ignoring that a certificate also creates backing key and secret objects.
- Allowing exportable private keys for cluster-internal mTLS without a specific need.
- Letting cert-manager and Key Vault renewal policies race without a clear owner of renewal timing.
- Treating integrated CA setup as safe without checking requester credential scope and contacts.

## Officially grounded service shape

Microsoft Learn evidence says a Key Vault certificate creates addressable key and secret objects, has a policy that controls issuer, key properties, exportability, lifetime actions, and renewal behavior, and can use integrated issuers such as DigiCert and GlobalSign. Exportability controls whether private key material can be retrieved from the backing secret. Certificate contacts and Event Grid support lifecycle notification, and RBAC should separate certificate lifecycle permissions from broader vault administration.

- A Key Vault certificate policy defines subject/SANs, key properties, exportability, secret content type, lifetime actions, issuer, and validation type.
- Integrated issuers can automate renewal for supported CAs; nonintegrated CAs require different renewal automation or manual process.
- Certificate lifecycle events need contacts or event routing to accountable responders.
- Private endpoint and DNS posture determine whether AKS workloads can reach a locked-down vault.
- RBAC decisions must distinguish control plane, data plane, certificate, secret, and purge/recover operations.

## Non-negotiable design rules

- Prefer the least data-plane certificate role required; do not grant broad vault administration to cert-manager by default.
- Flag exportable certificates when private key extraction is unnecessary for the workload.
- Validate issuer object, certificate policy, lifetime action, contacts, and CA credential scope together.
- Check AKS network path and private DNS before declaring a private vault usable.
- Never request private keys, PFX content, CA passwords, or requester credentials in chat.

## Minimal safe implementation flow

- Scope the certificate issuer, Key Vault, AKS cluster, managed identity, namespaces, and certificate consumers.
- Review policy fields: issuer, key type/size, exportable, reuse key on renewal, SANs, lifetime action, enabled state, and tags.
- Review RBAC and network evidence without exposing credentials or private key material.
- Compare cert-manager renewBefore behavior against Key Vault lifetime action and owner expectations.
- Return severity-labeled findings with source labels and safe remediation path.

## High-risk assumptions to kill

- Certificate data-plane work does not require broad Key Vault or resource-group management-plane access by default.
- A Key Vault certificate is also backed by key and secret objects; certificate review must include private-key retrieval and backing-secret implications.
- `exportable` certificates are dangerous for mTLS and internal trust unless private-key extraction is explicitly required and audited.
- Integrated CA renewal does not remove the need for contacts, lifecycle events, owner response, and failed-renewal handling.
- Private endpoint enabled on the vault is insufficient unless AKS DNS, firewall, and egress paths are proven for the issuer workflow.

## Safe command/code verification targets

- Inspect certificate policy JSON or IaC for issuer, subject/SANs, key type/size, exportable, reuse-key-on-renewal, lifetime actions, secret content type, and enabled state.
- Review role assignments for certificate lifecycle permissions separately from secret, key, purge, and management-plane permissions.
- Check cert-manager issuer manifests or automation for managed identity binding, namespace scope, renewal timing, and absence of embedded CA credentials.
- Verify Key Vault network definitions include private endpoint, private DNS zone links, firewall posture, and AKS egress compatibility.
- Confirm monitoring covers certificate near-expiry, expiry, renewal success/failure, export operations, delete/recover/purge events, and accountable responders.

## Safe verification targets

- Managed identity has only required certificate operations, not broad vault delete or purge authority.
- Certificate policies align with organizational issuer, key, exportability, and validity standards.
- Renewal contacts/events exist and route to an accountable owner.
- Private endpoint, firewall, and DNS path match the AKS connectivity model.
- Rollback plan exists for failed renewal, wrong issuer, or bad private DNS change.

## When to push back

- The request asks to export private keys without a documented break-glass need.
- The identity has broad Contributor or Administrator posture and the user wants to accept it as fine.
- Issuer credentials are account-wide or unmanaged.
- No owner can explain whether Key Vault or cert-manager owns the next renewal event.

# Documentation and Evidence Path

## Preferred evidence order

1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
2. Sampled read-only Azure or Kubernetes evidence, when safely available, for current configured-environment observations.
3. Sanitized user-provided evidence.
4. Clearly labeled inference.

## What each evidence type can prove

- Microsoft Learn documentation can prove documented service behavior, supported concepts, and recommended patterns.
- Sampled read-only evidence can prove the sampled configured state at the time observed.
- Sanitized user evidence can prove only what the snippet shows.
- None of these alone prove broad regional availability, future success, full account posture, or production readiness.

## Safe usage pattern

- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
- Use read-only queries before recommending changes.
- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

## Asset guidance

Use Microsoft Learn documentation through the user's configured documentation MCP for documented Key Vault certificate behavior. Use sampled read-only Azure evidence only for certificate policy, issuer, RBAC, network, and renewal observations; never request private keys or CA account secrets.

# Official Sources

Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, RBAC, quotas, deployed resources, or production readiness.

## Primary Microsoft Learn sources

- https://learn.microsoft.com/azure/key-vault/certificates/about-certificates
- https://learn.microsoft.com/azure/key-vault/certificates/secure-certificates
- https://learn.microsoft.com/azure/key-vault/certificates/overview-renew-certificate
- https://learn.microsoft.com/azure/key-vault/certificates/tutorial-rotate-certificates
- https://learn.microsoft.com/azure/key-vault/certificates/how-to-integrate-certificate-authority
- https://learn.microsoft.com/azure/key-vault/certificates/how-to-export-certificate
- https://learn.microsoft.com/azure/key-vault/general/rbac-guide
- https://learn.microsoft.com/azure/key-vault/general/network-security

## Grounding notes

- Documentation-based claim: Microsoft Learn evidence says a Key Vault certificate creates addressable key and secret objects, has a policy that controls issuer, key properties, exportability, lifetime actions, and renewal behavior, and can use integrated issuers such as DigiCert and GlobalSign. Exportability controls whether private key material can be retrieved from the backing secret. Certificate contacts and Event Grid support lifecycle notification, and RBAC should separate certificate lifecycle permissions from broader vault administration.
- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
- Inference: allowed only when labeled and tied to observed fields or documented behavior.
- Do not include sensitive internal identifiers or secret material in findings.

## Source use rules

- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
- Use sampled read-only Azure evidence only to validate current configured-environment observations.
- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

# Safety Checklist

## Evidence labels

- `documentation-based`: grounded in Microsoft Learn or official Kubernetes documentation where listed.
- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
- `user-provided`: grounded in sanitized snippets supplied by the user.
- `inference`: reasoned from evidence but not directly proven.

## Mutation boundary

- Default to read-only review.
- Do not perform create, update, delete, rotate, purge, recover, apply, restart, drain, cordon, scale, rollout, role-assignment, policy-assignment, or network changes unless the user explicitly asks and approval is clear.
- Prefer preview, dry-run, status, describe, what-if, list, show, and policy evaluation evidence before any mutation.

## Credential and data boundary

- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, or connection strings.
- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.

## Risk gates

- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, or missing owner for high-impact assets.
- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive operations, and live rollout changes as high-risk.
- Separate documented product behavior from sampled configured-environment evidence.

## Asset-specific hard line

Use Key Vault certificate data-plane roles for certificate lifecycle tasks and avoid broad management-plane roles. Treat exportable private keys, unscoped CA requester credentials, missing renewal contacts, and untested renewal handoff as high-risk.

# Workflow and Output Contract

## Execution flow

1. Scope the exact asset, environment boundary, owner, and requested decision.
2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
3. Gather sampled read-only evidence only when available and safe.
4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
5. Return a verdict with evidence level, blockers, safe next actions, and open questions.

## Required output

- `verdict`: pass, warn, fail, or blocked.
- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
- `scope`: what was reviewed and what was not reviewed.
- `blockers`: issues that prevent a safe or production-ready conclusion.
- `findings`: severity-labeled risks with source labels.
- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
- `open_questions`: missing facts that would change the verdict.

## Stress checks

- What assumption would make this recommendation unsafe?
- Which role, policy, network, lifecycle, or rollout action has the largest blast radius?
- What evidence would disprove the claimed readiness?
- Is the answer accidentally treating documentation as tenant-specific proof?

## Response discipline

Use Microsoft Learn documentation through the user's configured documentation MCP for documented Key Vault certificate behavior. Use sampled read-only Azure evidence only for certificate policy, issuer, RBAC, network, and renewal observations; never request private keys or CA account secrets.