Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Move config and challenge result to legacy issuer package #596

Closed
wants to merge 3 commits into from

Conversation

nsmith5
Copy link
Contributor

@nsmith5 nsmith5 commented May 18, 2022

Summary

This work finally pushes the existing identity issuer logic behind the identity.IssuerPool abstraction. This is done by

  • Moving the challenges.ChallengeResult type to the legacy issuer package. This is renamed legacyPrincipal and all implementation details are unexported. ChallengeResult implementes the identity.Principal interface.
  • Moves config.FulcioConfig into the legacy issuer package. This is renamed legacyIssuer and all implementation details are unexported. It now implements the identity.Issuer interface.
  • Change the grpc server to consume an identity.IssuerPool
  • Load the issuer pool with the legacy issuer above

NB: Currently in draft because there are now a bunch of merge conflicts 馃槵 Posting now to get an early set of eyes if the approach makes sense.

Ticket Link

Related to #275

Signed-off-by: Nathan Smith <nathan@chainguard.dev>
Moves config and challenge result into legacy issuer package. API
servers now use issuer pool containing the legacy issuer.

Signed-off-by: Nathan Smith <nathan@chainguard.dev>
Signed-off-by: Nathan Smith <nathan@chainguard.dev>
@nsmith5
Copy link
Contributor Author

nsmith5 commented May 18, 2022

Hmm I see I've broken the stuff under /federate by unexporting the FulcioConfig data structure and hiding it under the legacy package 馃 If this is important, perhaps schema of the configuration can be public (like keep the config package and FulcioConfig type around but remove the private fields like the LRU cache etc) and the details of how its parsed and used in the legacy package can be private?

Copy link
Contributor

@haydentherapper haydentherapper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR might benefit from being split into two. In particular, it's not totally clear what the transition away from FulcioConfig will look like, so maybe some high level examples in the PR description too?

TypeVal: challenges.EmailValue,
Value: "foo@example.com",
}, priv.Public())
precsc, err := ica.CreatePrecertificate(context.TODO(), testPrincipal{}, priv.Public())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move away from fakes to use real instances?

Can we instead use legacyPrincipal{} on line 177 instead of testPrincipal{} and populate it with test values, so that we can use the real implementation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could, but this test doesn't check anything that actually changes if you change the implementation of identity.Principal used from what I can see.

}

func NewGRPCCAServer(ct *ctclient.LogClient, ca certauth.CertificateAuthority) fulciogrpc.CAServer {
func NewGRPCCAServer(ct *ctclient.LogClient, ca certauth.CertificateAuthority, ip identity.IssuerPool) fulciogrpc.CAServer {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I'd pick a different var name since ip is typically used for networking

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup good point

// top-level and second-level domain
const minimumHostnameLength = 2

type legacyIssuer struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this configuration goes away after the refactor?

It's a bit hard to tell why we're moving this, especially given this file has gotten huge. Should this be split up?

@@ -47,35 +47,19 @@ type grpcServer struct {
caService gw.CAServer
}

func passFulcioConfigThruContext(cfg *config.FulcioConfig) grpc.UnaryServerInterceptor {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To confirm, this removal is because we're now adding the config to the context in Authenticate?

@haydentherapper
Copy link
Contributor

I think we should explore that more - I think the FulcioConfig is a good top-level abstraction over all supported configs.

On the note of LRU, we should still maintain the cache and make sure we're preloading the keys, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants