Philippe Martin
df15133c89
Move non-secret environment defaults and discovery keys into bounded profile declarations. Validate credential collisions and required platform adapters, and keep profile revision encoding deterministic. Preserve sandbox template and spec environment values, including empty values, over non-secret profile defaults in both launch paths. Keep provider credential placeholders authoritative. Allow identical non-secret values from attached providers while rejecting conflicting values and credential key collisions. Never expose GOOGLE_SERVICE_ACCOUNT_KEY through credentials or non-secret defaults, including older stored profiles. Omit stale private-key records without withholding remaining Vertex tokens or SDK configuration. Remove ID-selected adapters and orphaned GCP metadata helpers; document migration and compatible example imports. Closes #3442 BREAKING CHANGE: Google Cloud and Vertex profiles must declare their environment and discovery effects. The Google Cloud metadata profile requires the currently unavailable gcp-metadata adapter. Configure Vertex private key material through credential refresh instead of GOOGLE_SERVICE_ACCOUNT_KEY. Signed-off-by: Philippe Martin <phmartin@redhat.com>
Example provider profiles
These files are reviewable examples. OpenShell does not compile them into any binary and no gateway loads them on its own: a gateway's profile catalog contains exactly what an operator imported.
Import one at platform scope:
openshell provider profile lint -f providers/github.yaml
openshell provider profile import -f providers/github.yaml --global
To import several profiles, put compatible copies in a separate directory:
openshell provider profile import --from ./selected-profiles --global
Drop --global to import into the current workspace instead.
The google-cloud.yaml example requires the gcp-metadata platform adapter,
provided for Linux sandboxes by the supervisor. Windows/MXC does not provide
this adapter. The Vertex example uses bearer-token authentication and does not
require it.
Read the header before importing
Every file opens with a comment block naming its expected client binaries, the
image layout those paths assume, the credential scope, the endpoint access it
grants, and a smoke test. Read it. A profile's binaries list is the control
that decides which processes may reach its endpoints, and several of these
examples name paths from a particular reference image layout
(/sandbox/.venv, /app/.venv, /sandbox/.cursor-server,
/usr/lib/node_modules/...). Imported unchanged into a different image, such a
profile matches nothing: the catalog still advertises it, but the credential is
never injected and the traffic is denied.
Copy the file, edit binaries and endpoints to match your image and your
workload, and import your copy.
Adapting one
- Give your copy a distinct
idif it diverges from the example, so the two cannot be confused in the catalog. - Keep
binariesas narrow as the workload allows. Widening it to match every image trades away the binary-scoped least privilege that makes credential injection safe. - Keep
endpointslimited to the hosts the credential should reach. A credential is only sent to the endpoints its profile declares. - Review non-secret
environmentdefaults,discovery.config_env_vars, andrequired_platform_adapter. Renaming the profile preserves these declarations. - Run
openshell provider profile lintbefore importing.
See Provider profiles for the full schema.