Upwind

C Upwind cloud security platform

The Upwind API, Terraform provider, CI actions and sensors all authenticate with an OAuth client ID and secret swapped for a 24-hour token; no OIDC or workload identity path exists. API credentials are role-scoped and show last use, but secrets never expire, have no management API and are not GitHub partner-revoked. Into your cloud it is keyless on AWS, Azure and GCP; OCI, classic Azure and several SaaS integrations still want static secrets.

Docs: docs.upwind.io · Checked 2026-10-22 · source YAML · dispute via PR

Inbound C

How a workload running anywhere authenticates to this product.

Upwind client credentials (client ID + client secret) generated under Settings > Access management > Credentials, exchanged at auth.upwind.io/oauth/token (grant_type=client_credentials) for a bearer JWT that expires after 24 hours. The same secret type is used by the Management REST API v1/v2, the Terraform provider, the GitHub Actions and CLI, Kubernetes and host sensors, and in-account Cloud Scanners reporting back to Upwind.

docs.upwind.io checked 2026-10-22
“To access the endpoints of the API, you need to authenticate your requests. We use OAuth 2.0, a widely adopted industry standard for authorization, to secure and control access to the API.”
docs.upwind.io checked 2026-10-22
“--data-urlencode 'client_secret=YOUR_CLIENT_SECRET'”
docs.upwind.io checked 2026-10-22
“--data-urlencode 'grant_type=client_credentials'”
docs.upwind.io checked 2026-10-22
“This documentation provides a comprehensive guide to creating secure Upwind credentials using OAuth2 and outlines best practices to safeguard the authentication and authorization processes.”
docs.upwind.io checked 2026-10-22
“All tokens automatically expire after 24 hours.”
docs.upwind.io checked 2026-10-22
“Copy the client ID and client secret. The secret is shown once.”
docs.upwind.io checked 2026-10-22
“upwind_client_secret: ${{ secrets.UPWIND_CLIENT_SECRET }}”
docs.upwind.io checked 2026-10-22
“--set credentials.clientSecret=$UPWIND_CLIENT_SECRET”
docs.upwind.io checked 2026-10-22
“Provide the Upwind Auth credentials using an AWS secrets manager secret.”

Graded C on the static-root rule (same as `paloalto-prisma-cloud` and `cyera-data-security`): the bearer token lives 24 hours, but minting it needs a long-lived client secret held by the workload. No OIDC, GitHub Actions OIDC, cloud workload identity or token-exchange login is documented anywhere in the docs site (all ~700 pages were searched); Upwind's own GitHub Actions store UPWIND_CLIENT_SECRET in GitHub Secrets rather than trusting the runner's OIDC token, and Cloud Scanners deployed in your account (Outpost model, Azure scanners) keep Upwind client credentials in AWS Secrets Manager or Azure Key Vault. docs.upwind.io is a client-rendered Docusaurus site, so receipts cite the page content bundles actually fetched; the matching human-readable pages are /restapi/v1/introduction, /restapi/v2/introduction, /settings/credentials, /terraform-provider/configuration, /code/ci/github-actions, /getting-started/install-sensor/kubernetes/install and /getting-started/connect-cloud-account/aws/outpost/glossary. No tier gate is documented.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

AWS onboarding provisions IAM roles that Upwind's SaaS Trust Account assumes with an Upwind-generated External ID; Azure uses service principals for Upwind's multi-tenant apps that Upwind reaches through federated credentials; GCP and OCI onboarding configure Workload Identity Federation from Upwind's AWS environment. OCI's federation still requires handing Upwind a confidential app client secret, the Azure classic flow and Azure activity-log integration use an app client secret, and several SaaS integrations take static tokens.

docs.upwind.io checked 2026-10-22
“All cross-account access uses AWS IAM assume-role with a scoped trust policy.”
docs.upwind.io checked 2026-10-22
“A value, generated by Upwind and unique to each AWS Organization, added to the trust policy of the IAM roles Upwind assumes.”
docs.upwind.io checked 2026-10-22
“Cross-tenant access is built on standard Microsoft Entra ID mechanisms: the customer tenant holds Upwind service principals with scoped role assignments, and Upwind's scanning workloads obtain short-lived tokens for those service principals through federated authentication.”
docs.upwind.io checked 2026-10-22
“Authentication is federated and short-lived; no standing customer-side credentials exist.”
docs.upwind.io checked 2026-10-22
“Upwind's SaaS onboarding uses two multi-tenant applications registered in Upwind's own Microsoft Entra tenant, so this step does not create an application or a client secret in your tenant.”
docs.upwind.io checked 2026-10-22
“Classic onboarding authenticates Upwind through an application registration and client secret in your own Microsoft Entra tenant.”
docs.upwind.io checked 2026-10-22
“This will grant access to your Google Cloud environment specifically from Upwind's AWS environment.”
docs.upwind.io checked 2026-10-22
“This configuration is essential for enabling Upwind to authenticate and interact with your Google Cloud resources without needing to manage long-lived credentials.”
docs.upwind.io checked 2026-10-22
“confidential_app_client_secret”
docs.upwind.io checked 2026-10-22
“Unique external ID generated by Upwind to establish secure cross-account access.”
docs.upwind.io checked 2026-10-22
“Upwind will retrieve the new service principal credential from the key vault and test connectivity to the Event Hub.”
docs.upwind.io checked 2026-10-22
“Step 2. Install the Upwind GitHub App”
docs.upwind.io checked 2026-10-22
“GitLab has no API for creating an OAuth application, so you create one on your”
docs.upwind.io checked 2026-10-22
“An OpenAI Admin API key carries organization management permissions; OpenAI does not offer a”

Checked cloud onboarding: AWS SaaS and Outpost (IAM roles trusting Upwind's account with an External ID; keyless), Azure SaaS and Outpost (service principals for Upwind's multi-tenant apps via admin consent; SaaS scanner workers use federated credentials; keyless), Azure classic onboarding (app registration client secret, "ideally 24 months"; optional legacy path), GCP (WIF from Upwind's AWS environment; keyless), OCI (WIF, but the onboarding asks for an identity domain confidential app's client ID and secret, so a static secret is handed over). Integrations: AWS CloudTrail and object-storage export (assumed role, External ID), GuardDuty and Defender for Cloud (no customer secret), GCP Cloud Audit Logs (WIF), Azure Activity Logs (service principal client secret that Upwind reads from your Key Vault), GitHub (GitHub App), GitLab and ServiceNow (OAuth app client secret), Jira (Atlassian OAuth 3LO), Snowflake (key-pair or programmatic access token), Databricks (service principal OAuth secret), OpenAI (Admin API key), Datadog (API key), Splunk (HEC token). The Upwind client credentials that the Outpost templates and Cloud Scanners carry are Upwind's own inbound credential (graded above), not a secret into your cloud. Keyless on all three major clouds, so B rather than C; OCI WIF without a client secret, or federation for Azure activity logs, would move it toward A for clouds, though SaaS integrations would still hold static tokens.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Only the 24-hour access token expires. The credentials page lists name, client ID, last used, scope and modification fields but no expiry, the generate dialog asks only for type and name, and no organization policy to cap a client secret's lifetime is documented. A secret lives until someone revokes it. docs.upwind.io checked 2026-10-22 “When API credentials are removed, any existing active tokens will remain functional until they expire.” docs.upwind.io checked 2026-10-22 “Using multiple credentials lets you rotate them as part of your security practice, or revoke a specific key if it's inadvertently exposed.”
✗ Rotation via API	Credentials are generated and revoked in the console. The Management REST API v1 and v2 references (access management covers members, groups, roles and scopes) and the Terraform provider's five resources have no endpoint or resource for client credentials, so rotation cannot be automated without a browser. Not publicly verifiable whether an undocumented endpoint exists. docs.upwind.io checked 2026-10-22 “From the top of the side pane, by clicking on the three dots icon and” docs.upwind.io checked 2026-10-22 “Settings > Access management> Credentials”
✓ Scoped keys	API credentials are organization-level machine principals with their own RBAC scope and roles, bounded by (never exceeding) the creator's access, which the rubric counts. Sensor, Cloud account and Integration credentials cannot be scoped, but are purpose-typed for one job. docs.upwind.io checked 2026-10-22 “When creating Upwind API credentials, you must assign specific permissions; any token generated from these credentials will inherit those access levels. You can mirror the permissions of an existing member group or define a custom scope and roles.” docs.upwind.io checked 2026-10-22 “No, you can only set scope and roles on credentials of API type.”
✓ Last-used visible	The Credentials table has a "Last used" column for every credential. docs.upwind.io checked 2026-10-22 “Timestamp indicating the most recent usage of these credentials.”
✗ Leak revocation	Upwind does not appear in GitHub's supported secret scanning patterns table, so a leaked Upwind client secret is neither detected nor reported to Upwind for revocation. docs.github.com checked 2026-10-22

Notes

One card for the Upwind platform (CNAPP: Cloud Scanners, sensors, Code/shift-left, API security, identity and AI security share one credential system and one Management API). Two of five hygiene checks pass (scoping, last used). Inbound moves to B or A only if Upwind accepts a federated token (GitHub Actions OIDC, cloud workload identity or a bring-your-own issuer) for the API, CI actions and sensors; a credential management API and an enforced secret lifetime would add hygiene passes but do not change a C. Outbound reaches A for clouds if OCI onboarding drops the confidential app secret and the classic Azure flow is retired.

Badge

[![wif.tax grade](https://wif.tax/badge/upwind.svg)](https://wif.tax/p/upwind/)