docs: add AWS, GCP, and Azure secrets provider documentation

[markphelps]

Add documentation for three new cloud secrets providers:

• AWS Secrets Manager: configuration, authentication via AWS credential chain, custom endpoints for LocalStack
• GCP Secret Manager: configuration, ADC and service account auth, regional secrets support
• Azure Key Vault: configuration, DefaultAzureCredential auth methods

Also updates the pro.mdx page to reflect that cloud provider support is now available (no longer "coming soon").

Closes #398, Closes #390

https://claude.ai/code/session_01KAfEyV81ZochM2Z9dT9CKB

[claude]

PR Review: docs: add AWS, GCP, and Azure secrets provider documentation

Overall this is a well-structured PR that delivers on its core purpose. The new cloud provider documentation sections are clear, consistent, and follow the existing patterns established by the Vault and File provider sections. Here is my detailed feedback.

What is working well

docs/v2/configuration/secrets.mdx — the main deliverable is solid:

• Each new provider (AWS, GCP, Azure) has a consistent structure: Configuration table, Authentication, Environment Variables
• Configuration tables are complete with type, required, default, and description columns
• Links to external provider documentation (AWS credential chain, GCP regional secrets, Azure DefaultAzureCredential) are accurate and helpful
• The LocalStack custom endpoint example for AWS is a useful practical touch
• The Cloud Provider Examples section at the bottom ties it all together nicely
• Removing the "coming soon" Tip and updating pro.mdx are the right housekeeping moves

---

Issues

1. Unrelated change to docs/reo.js — should be reverted

This file is a third-party analytics snippet (Reo.dev). The change wraps the comma expression in extra parentheses and moves the closing paren. While functionally equivalent, this is almost certainly an accidental Prettier reformatting of a vendor/minified file. Vendor scripts should be kept in their original form or updated by replacing the whole file from the source. This change has no relation to the PR stated purpose.

Recommendation: Revert docs/reo.js to its original form.

---

2. Large unrelated reformatting in docs/v1/guides/migration/launchdarkly/openfeature.mdx

This file has 96 additions and 75 deletions consisting entirely of trailing comma additions to JavaScript code samples in documentation. These are syntactically correct and arguably more modern style, but they are completely unrelated to cloud secrets providers. Including them adds noise to the diff and makes it harder to review the actual content changes. They also only affect one guide, suggesting a partial Prettier run rather than an intentional documentation update.

Recommendation: Either revert these changes and open a separate cleanup PR, or run npm run format across all docs consistently and include that as a separate commit/PR.

---

Minor suggestions

3. New provider cards lack section links

The three new Card components in the CardGroup do not include href attributes pointing to the new sections below. Users clicking a card would likely expect to land on the relevant section. For example:

<Card title="AWS Secrets Manager" icon="aws" href="#aws-secrets-manager-provider">
  Retrieve secrets from AWS Secrets Manager using standard AWS credentials
</Card>

The existing File and Vault cards also lack links, so this is a pre-existing gap, but now that there are six options it is worth addressing for discoverability.

---

4. AWS section is missing AWS_SESSION_TOKEN

The AWS environment variables section shows AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, but for users with temporary credentials (STS, assumed roles, CI/CD), AWS_SESSION_TOKEN is commonly required alongside these. Worth a one-line mention or including it in the example.

---

5. Secret reference key format: clarify path and versioning support

The Vault examples show nested paths (flipt/tokens:ci-token) but the cloud provider examples only show flat keys (${secret:gcp:git-token}). It would help to clarify whether AWS/GCP/Azure keys can include path separators or version specifiers — for example, AWS Secrets Manager supports ARNs and version stages in secret references. If only the exact secret name is supported, a brief note to that effect would prevent user confusion.

---

Summary

File	Assessment
docs/v2/configuration/secrets.mdx	Good — core content is complete and well-structured
docs/v2/pro.mdx	Good — correct housekeeping update
docs/v1/authorization/overview.mdx	Fine — minor blank line cleanup
docs/v1/guides/migration/launchdarkly/openfeature.mdx	Recommend separating — unrelated reformatting
docs/reo.js	Recommend reverting — unrelated vendor script modification

The documentation content itself is at the right level of detail, covers the essential auth methods for each provider, and follows existing patterns. The main asks before merging are reverting docs/reo.js and separating the unrelated formatting changes in the LaunchDarkly guide.

[claude]

PR Review: AWS, GCP, and Azure Secrets Provider Documentation

Overall this is a solid, well-structured addition. The new provider docs follow the existing patterns nicely and cover the key areas (configuration, auth, env vars). A few things worth looking at:

---

Minor Issues

1. Contradictory wording in the AWS env vars section (secrets.mdx, ~line 220)

The AWS_SESSION_TOKEN comment reads:

export AWS_SESSION_TOKEN="your_session_token" # Optional: required for temporary credentials (STS, assumed roles)

"Optional" and "required" in the same description is contradictory. Suggest rewording to:

export AWS_SESSION_TOKEN="your_session_token" # Only needed for temporary credentials (STS, assumed roles)

2. Since version in overview.mdx tables

All three new provider properties show v2.0.0 in the Since column:

| secrets.providers.aws.endpoint_url | ... | | v2.0.0 |

If these providers are being shipped in a release after v2.0.0 (e.g., v2.1.0 or v2.2.0), these values should reflect the actual release version in which they're introduced.

3. pro.mdx — "Multiple Providers" bullet feels incomplete

The "Multiple Providers" bullet still reads:

HashiCorp Vault integration with secrets references throughout configuration

Now that AWS, GCP, and Azure are supported (not just Vault), this bullet undersells the feature. It might be worth updating to something like:

Multiple provider integrations (HashiCorp Vault, AWS, GCP, Azure) with secrets references throughout configuration

---

Positive Notes

• Removing the "coming soon" tip and replacing it with actual provider docs is the right move.
• Adding href anchors to the Cards is a good UX improvement.
• The limitation callout in Cloud Provider Examples is important and appreciated:

  Path separators and version specifiers are not supported in the key — use the secret's name directly.

• Auth chain documentation for all three providers is thorough without being excessive.
• The v1/authorization/overview.mdx blank-line removals look fine for Mintlify's MDX rendering.

---

The three items above are all minor — none of them block this PR. Nice work cleaning up the "coming soon" state and getting these provider docs landed.

[claude]

PR Review: Add AWS, GCP, and Azure Secrets Provider Documentation

Overall this is a well-structured addition that follows the existing documentation patterns. The new provider sections are comprehensive and the writing is clear. A few things worth addressing:

---

Issues

1. Unrelated change in docs/v1/authorization/overview.mdx

The removal of blank lines before nested list items in the authorization doc appears unrelated to this PR's purpose. In Markdown/MDX, blank lines between list items affect rendering (tight vs. loose lists), so this isn't purely cosmetic. If this was an intentional fix, it should be explained in the PR description or split into a separate commit. If unintentional (e.g., from autoformatting), it should be reverted.

2. Since column may be incorrect in overview.mdx

The new configuration table entries for AWS, GCP, and Azure all show v2.0.0 in the Since column:

| secrets.providers.aws.endpoint_url | ... | | v2.0.0 |
| secrets.providers.gcp.project      | ... | | v2.0.0 |

If these providers are being shipped in a version after v2.0.0, the Since values should reflect the actual release version. The existing Vault entries also show v2.0.0 — but if AWS/GCP/Azure support is new, that version needs to be updated to match when it actually ships.

3. azure_ad OIDC provider name in the example may be misleading

In the "Cloud Provider Examples" section, the YAML uses azure_ad as the OIDC provider key:

authentication:
  methods:
    oidc:
      providers:
        azure_ad:
          client_id: "${secret:azure:oidc-client-id}"

Is azure_ad the actual provider name as configured in Flipt, or a placeholder? The HashiCorp Vault example above uses google as the OIDC provider key (which matches real Flipt config). If azure_ad isn't the actual key users would configure, this could cause confusion. A note clarifying that the key matches whatever name the user gives their OIDC provider would help.

---

Minor Observations

4. pro.mdx card lost mention of "secrets references"

The original Card description mentioned "secrets references" as a distinct feature:

"with HashiCorp Vault integration and secrets references"

The updated version lists providers but drops this:

"with HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault"

The secrets reference syntax (${secret:provider:key}) is a meaningful user-facing feature. Consider preserving a mention of it, e.g. "...and Azure Key Vault, with secrets references throughout your configuration."

5. No mention of secret version/latest behavior

AWS Secrets Manager supports version stages (e.g., AWSCURRENT) and GCP supports explicit version numbers. The docs don't clarify whether Flipt always retrieves the latest/current version, or if users can pin to a specific version via the key. Even a brief note like "Flipt always retrieves the current version of the secret" would set expectations correctly.

---

What's Working Well

• The structure and heading hierarchy mirror the existing Vault section closely — easy to follow.
• Adding href anchors to the provider Cards is a nice improvement.
• Authentication methods for each provider are clearly documented with both YAML and env var examples.
• The custom endpoint section for LocalStack is a useful practical addition.
• Removing the "coming soon" callout is the right call now that these providers are available.

[claude]

PR Review: Add AWS, GCP, and Azure Secrets Provider Documentation

The documentation content is clear, well-organized, and follows the existing patterns. A few items worth addressing before merge:

---

Issues

1. Contradictory comment on AWS_SESSION_TOKEN (secrets.mdx)

The inline comment reads:

export AWS_SESSION_TOKEN="your_session_token" # Optional: required for temporary credentials (STS, assumed roles)

"Optional" and "required" directly contradict each other. Suggested fix:

export AWS_SESSION_TOKEN="your_session_token" # Only needed for temporary credentials (STS, assumed roles)

---

2. Since version may be incorrect in overview.mdx

All three new provider table entries show v2.0.0:

| secrets.providers.aws.endpoint_url | ... | | v2.0.0 |
| secrets.providers.gcp.project      | ... | | v2.0.0 |
| secrets.providers.azure.vault_url  | ... | | v2.0.0 |

If these providers are being introduced in a release after v2.0.0, these values should reflect the actual shipping version. Please verify.

---

3. Inconsistent abbreviation style in overview.mdx

The new Azure table entry uses e.g., while the corresponding entry in secrets.mdx uses "for example":

• overview.mdx: Azure Key Vault URL (e.g., https://my-vault.vault.azure.net/`)`
• secrets.mdx: Azure Key Vault URL (for example, https://my-vault.vault.azure.net/`)`

Per the Microsoft Writing Style Guide, prefer "for example" over "e.g." Recommend updating the overview.mdx entry to match.

---

4. Unrelated change in docs/package-lock.json

Three packages (acorn, eslint, prettier) had "peer": true added to their lockfile entries. This appears to be an incidental side effect of running npm install and is unrelated to the documentation content. Recommend reverting to keep the diff focused.

---

5. pro.mdx — "Multiple Providers" bullet is still Vault-only

The bullet was not updated alongside the card text above it:

Multiple Providers: HashiCorp Vault integration with secrets references throughout configuration

Now that AWS, GCP, and Azure are supported, this undersells the feature. Consider:

Multiple Providers: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault, with secrets references throughout configuration

---

Summary

Items 1, 3, and 5 are straightforward one-line fixes. Item 2 needs a version check with whoever owns the release. Item 4 is a cleanup that keeps the PR scope clean. The core documentation content is solid — the provider structure, auth documentation, and examples are all well done.