This commit adds support for the remote configuration of the GCP
organization id.
It also reverts a change in smallstep/certificates#2331. Now the
projects service client is initialized just once, instead of doing it on
every operation.
Related to smallstep/cli#1449
This commit replaces the client in provisioners and webhooks with an
interface. Then it implements the interface using the new poolhttp
package. This package implements the HTTPClient interface but it is
backed by a sync.Pool, this improves memory, allowing the GC to clean
more memory. It also removes the timer in the keystore to avoid
having extra goroutines if a provisioner goes away. This commit avoids
creating the templates func multiple times, reducing some memory in the
heap.
Before this commit, users could specify a hardcoded list of project IDs
to restrict access to the GCP provisioner. While this works, it can be
both toilsome to the team maintaining the Smallstep installation and
unintuitive to the internal infrastructure users that may encounter
errors as a result of their project not being added.
This commit is a rough attempt at adding support for validating that a
GCP project belongs to a given GCP organization. It does this by using
the `projects.getAncestry` call in the Cloud Resource Manager API. If
a token's project claim does not have the given organization ID as its
topmost ancestor, the token is rejected. This will require the
`resourcemanager.projects.get` IAM permission on the organization.
The new `OrganizationID` configuration directive is compatible with the
existing `ProjectIDs` configuration. If `ProjectIDs` is non-empty, it
will take precedence over the `OrganizationID` and act as it did before,
with the minor difference that if `OrganizationID` is also non-empty,
the provisioner will check the project's ancestry before rejecting the
token.
There are a couple outstanding questions and tasks after this commit. I
tried to strike the right balance between production-ready and
proof-of-concept here, so I'm open to any suggestions.
- Is the `authority/provisioner/gcp` package the right place for adding
this functionality? Is the new struct the right approach?
- We should add tests for validating the organization ID.
- How should users configure the authentication for the Cloud Resource
Manager client? I expect this would be similar to the Cloud KMS
integration.
- Does Smallstep Professional run in an environment that will be able to
authenticate with Google? We would need to either grant permissions to
a Smallstep-owned Google service account if it's run in GCP, or set up
something like Google's Workload Identity Federation to handle a K8s,
AWS, or Azure deployment.
* internal/httptransport: initial implementation of the package
* authority: refactored for httptransport
* ca: refactored for httptransport
* test: refactored for httptransport
This commit adds a new field error in the webhook response that allows
to propagate errors to the client. With ACME, webhook errors are as
a new subproblem.
* Use dnsNamesSubsetValidator for IID provisioners
... when disableCustomSANs is set to 'true'.
The DNS names in the certificate request must be a subset of the
authorized set of DNS names (from the IID token). The previous
functionality required that the DNS names in the certificate request
exactly matched the authorized DNS names.
* Update authority/provisioner/sign_options.go
Co-authored-by: Herman Slatman <hslatman@users.noreply.github.com>
* Update authority/provisioner/sign_options.go
Co-authored-by: Herman Slatman <hslatman@users.noreply.github.com>
* Use map[string]struct rather than map[string]bool for clarity
---------
Co-authored-by: Herman Slatman <hslatman@users.noreply.github.com>
This commit upgrades go.step.sm/crypto with a version that adds support
for setting validity bounds in templates. It also adds support for these
in the certificate modifiers.
The priority for the validity bounds are:
1. Coming from flags.
2. Coming from the template.
3. Defaults.
