feat(azure): accept pre-minted access tokens for federated identity /OIDC

[jorgegmz]

Motivation

CloudSploit currently authenticates to Azure via ClientSecretCredential only — config.credentials.azure.application_id + key_value are required by both index.js (config parsing) and helpers/azure/auth.js (login()). This
blocks adoption in environments where no client secret exists, most notably:

• Federated workload identity / OIDC — where Azure issues short-lived tokens via the SDK's ClientAssertionCredential rather than a static secret.
• Managed identity scenarios where callers already hold a valid bearer.

These callers can mint the three audience-specific tokens that CloudSploit's plugins already consume, but there's currently no way to inject them.

Change

Strictly-additive support for a new AccessTokens config field that accepts a pre-minted trio:

module.exports = {
    credentials: {
        azure: {
            directory_id:    '...',
            subscription_id: '...',                                                                                                                                                   
            govcloud:        false,           // optional
            AccessTokens: {
                arm:   '...', // https://management.azure.com/.default
                graph: '...', // https://graph.microsoft.com/.default
                vault: '...', // https://vault.azure.net/.default
            },
        },
    },
};

Two files modified:

- index.js — new else if branch detects config.credentials.azure.AccessTokens during config parsing and builds cloudConfig from directory_id + subscription_id + the token trio. Placed before the existing application_id branch so
opt-in callers win when both are present.
- helpers/azure/auth.js — login() short-circuits when azureConfig.AccessTokens is present, returning the tokens directly via the same {token, graphToken, vaultToken} contract that plugins already consume. No plugin changes
required.

Govcloud branch handled — Govcloud: true flips the environment.name/portalUrl to AzureUSGovernment/https://portal.azure.us, matching the existing govcloud return.

Backward compatibility

Zero impact on existing users:

- The new AccessTokens field is opt-in. Configs that don't set it continue down the existing ClientSecretCredential path unchanged.
- No plugin changes — token routing per audience was already in place upstream.
- No new dependencies.

36 insertions, 0 deletions.

Testing

Tested locally against a real Azure subscription using tokens minted from @azure/identity's ClientAssertionCredential (federated OIDC trust). Two subscriptions, both commercial cloud, full posture scan completes with the same
finding distribution as a parallel ClientSecretCredential scan on the same subscription.

[CLAassistant]

All committers have signed the CLA.