Buildpacks Authentication

generated: '2026-09-05'
method: searched
source: >-
  https://github.com/buildpacks/registry-api (README + config/routes.rb), anonymous probes of
  https://registry.buildpacks.io/api/v1/*, openapi/buildpacks-kpack-swagger.json, and
  https://buildpacks.io/docs/for-buildpack-authors/how-to/distribute-buildpacks/publish-buildpack/
provider: Cloud Native Buildpacks
providerId: buildpacks
description: >-
  Cloud Native Buildpacks exposes three distinct authentication postures, none of them an
  API-key or OAuth program run by the project itself. Read access to the Buildpack Registry is fully
  anonymous; write access to the registry is delegated to GitHub identity; and the kpack CRD API
  inherits whatever the Kubernetes API server enforces. The kpack Swagger document declares no
  `securityDefinitions`, which is normal for a Kubernetes aggregated/CRD spec and is NOT an absence
  of auth — the cluster enforces it.
docs: https://buildpacks.io/docs/for-buildpack-authors/how-to/distribute-buildpacks/publish-buildpack/
surfaces:
- api: Buildpack Registry API (read)
  base_url: https://registry.buildpacks.io/api/v1
  scheme: none
  required: false
  verified: probed
  evidence: >-
    GET https://registry.buildpacks.io/api/v1/search?matches=java returned HTTP 200 with a JSON body
    with no credential of any kind on 2026-09-05. GET .../buildpacks/heroku/nodejs likewise 200.
  note: >-
    All three documented read operations (search, version list, version info) are public and
    unauthenticated. No API key, token, or account is issued by the project.
- api: Buildpack Registry (write / publish)
  scheme: delegated-oauth
  provider: GitHub
  required: true
  verified: searched
  evidence: >-
    https://buildpacks.io/docs/for-buildpack-authors/how-to/distribute-buildpacks/publish-buildpack/
    — "pack buildpack register example/my-cnb ... This will open GitHub in a browser and may ask you
    to authenticate with GitHub."
  note: >-
    Publication is not an HTTP write against registry.buildpacks.io. It is a structured GitHub Issue
    opened against the registry index; the authenticated GitHub user becomes the owner of the
    buildpack namespace on first publish. Namespace ownership changes are made by pull request to
    https://github.com/buildpacks/registry-namespaces.
- api: kpack (kpack.io/v1alpha1 CRD API)
  scheme: kubernetes
  mechanisms:
  - bearer token (ServiceAccount / OIDC)
  - client certificate
  - whatever authenticators the cluster's API server is configured with
  authorization: Kubernetes RBAC on the kpack.io API group
  required: true
  verified: derived
  evidence: >-
    openapi/buildpacks-kpack-swagger.json declares no `securityDefinitions`; every path is rooted at
    /apis/kpack.io/v1alpha1/ and is therefore served by the Kubernetes API server, which
    authenticates and authorizes the request before the kpack controller sees it.
  note: >-
    There is no CNB-issued credential here. An agent calling kpack authenticates to the customer's
    own cluster, not to buildpacks.io.
oauth2: false
api_keys: false
scopes_artifact: null
scopes_note: >-
  No OAuth 2.0 scope surface exists to derive. derive-oauth-scopes.py reported 0 oauth2
  securitySchemes on 2026-09-05; scopes/ is deliberately absent rather than empty.