Open imjasonh opened 2 years ago
cc @mattmoor since you were looking at KMS providers recently
Here's a concrete proposal:
pkg/providers
into sigstore/sigstore, as pkg/oidc/providers
pkg/providers/filesystem
into sigstore/sigstore as pkg/oidc/providers/filesystem
pkg/providers/github
into sigstore/sigstore as pkg/oidc/providers/github
pkg/providers/google
into sigstore/oidc-googlepkg/providers/spiffe
into sigstore/oidc-spiffepkg/providers/all
, and recommend folks do what it does itself, and _
-import whatever providers you may want.
pkg/providers/*
packages, including all
, and drop a bunch of dependencies from sigstore/cosignWith this arrangement, clients (incl cosign) that want to support these providers simply have to _
-import them, and if they don't depend on them, they don't take their dependencies.
cc @wlynch
Another bump: the filesystem
provider expects to find a token at /var/run/sigstore/cosign/oidc-token
-- if we move this to sigstore/sigstore I think we should see if we can have it look in /var/run/sigstore
first, and then fallback to .../cosign
for compatibility.
Or, keep the cosign
-looking behavior as a special internal provider only in the cosign codebase, and have sigstore's only look in sigstore
.
Description
github.com/sigstore/cosign/pkg/providers
provides an interface for OIDC token providers and some common implementations, in subpackages (e.g.,pkg/providers/google
).The interface is agnostic to providers' dependencies, and doesn't have any deps outside of the Go stdlib. Provider-specified implementations may have external dependencies, e.g.,
pkg/providers/google
depends ongoogle.golang.org/api/idtoken
.I'd like to propose we move at least the agnostic interface definition into sigstore/sigstore, and consider whether and how we should move the provider-specific impls out into their own modules -- either as submodules in sigstore/sigstore, or as separate repos, e.g.,
sigstore/oidc-google
,sigstore/oidc-github
, and so on.This would allow cosign and other implementations to selectively import OIDC providers they want to support, and not take a dependency on any others.
If this is successful, it may also give us a model to follow when moving KMS providers into separate modules or repos, for the same reasons.