openai-python v3.44.0

Version 3.44.0 of OpenAI's Python library lets an organization configure keyless access to the OpenAI API from code. The release has one feature: SDK methods for managing workload identity providers and federation rules, the two pieces of OpenAI's workload identity federation.

Workload identity federation removes the need to store an OpenAI API key in a server, container or CI job. According to OpenAI's guide, a workload presents a short-lived token it already holds from its own platform, for example a Kubernetes service account token, a cloud instance identity or a GitHub Actions OIDC token, and OpenAI exchanges it for a short-lived OpenAI access token. No refresh token is issued, so the workload repeats the exchange to renew. A workload identity provider tells OpenAI which external token issuer to trust and how to verify its tokens. A rule then decides which token attributes are accepted and which OpenAI service account the workload may act as; the guide calls this a service account mapping for the API and a federation rule for Codex.

OpenAI's guide walks through that setup in its dashboards. Pull request 4237 brings it into the Python library, adding create, retrieve, update, list and delete operations for OIDC workload identity providers, plus management of federation rules for existing project service accounts, including their attribute matchers and permissions. These calls require an Admin API key. An administrator can therefore script this setup instead of doing it by hand in the dashboards. The guide's limits still apply to whatever the SDK creates: a rule can only narrow the mapped service account's permissions, it cannot include Admin API scopes, and a token is issued only when exactly one enabled rule matches.