Comments (17)
Yeah, my biggest concern is that we settle with a design that is 1) internally consistent within the library, and 2) does not require breaking changes to expand
from go-spiffe.
@joewilliams I think next steps is addressing the feedback on the PR and getting that in. I appreciate your patience seeing this through!
from go-spiffe.
I think that sounds like a reasonable approach! We have lots of different packages. Would each package define its own "ClientTrace"-style struct and associated options that allow you to set it? There will probably be a little design work to ensure consistency of application to the various components.
I'm assume you are just targeting the go-spiffe v2 implementation?
I also wonder if this is sufficient to supplant the logger, which has felt a little invasive and something a few of us debated quite a bit before including.
from go-spiffe.
Would each package define its own "ClientTrace"-style struct and associated options that allow you to set it?
😅 I don' think we know yet but we'll dig in and find out.
I'm assume you are just targeting the go-spiffe v2 implementation?
Yes!
I also wonder if this is sufficient to supplant the logger, which has felt a little invasive and something a few of us debated quite a bit before including.
I think it certainly could replace it.
from go-spiffe.
@azdagron I pushed #150 with PoC
from go-spiffe.
@azdagron once we agree on an approach over in #150 it's unclear what might happen next. I think we'd be onboard to submit PR(s) for the areas/packages we use since we have a pretty good idea of what we'd want to measure with the metrics but I'm not sure we have the production knowledge to implement hooks in all the right places for everything else. Frankly, I don't think that would cover very many (tlsconfig, spiffeid, parts of workloadapi, etc). A half-implementation is likely worse than no implementation. What do you think?
from go-spiffe.
I'm sure once there is consensus that we can get somebody to work on it that is more familiar with the library. It should be a relatively scoped exercise and as long as we've done the plumbing of the trace structs correctly we don't need to worry about missing a start/end function here or there. Those should be able to be added later if needed.
from go-spiffe.
@azdagron any further thoughts on the approach in #150 Other than addressing the commenters issues, where do we go from here?
from go-spiffe.
I apologize. It's been a busy few weeks and this off my radar. I was talking to @evan2645 about this a few weeks back and we discussed prior art in other libraries. I've done some digging without success to see if there are established patterns outside of what is provided by httptrace
that we could align to. I haven't had much luck finding anything however. I think the current approach of providing a trace struct via options seems as good as any. It certainly gives us future proofing flexibility.
@amartinezfayo @evan2645 any concerns marching forward with the current approach?
from go-spiffe.
any concerns marching forward with the current approach?
I don't personally have a specific concern with the current approach. I'm guessing that we may need to make tweaks here and there as people start using this, but hopefully without structural changes.
from go-spiffe.
I haven't spent enough time looking at this change to endorse it specifically, but so long as we've considered existing patterns etc it sounds fine to me :)
from go-spiffe.
@azdagron i think we've addressed the reviewer comments in #150, any thing else we should look into before we squash and merge?
from go-spiffe.
We're really close. I took a final pass and found some things that I think need addressing but after those I think we're good to squash and merge. I appreciate your patience with the back-and-forth!
from go-spiffe.
@azdagron I think the next thing we'd want to implement this tracing pattern for are the verify related functions in tlsconfig. Does the align with what you are wanting?
from go-spiffe.
Yeah. I started digging into a PR for that and it brought up some questions around ergonomics that I'm still debating internally...
from go-spiffe.
This is still on my radar but I haven't had cycles to put more thought into it. Just wanted to make sure folks knew it hasn't been forgotten.
from go-spiffe.
@joewilliams, I'm so sorry this has fallen by the wayside.
I think next steps is figuring out at what granularity we want on the verification related tracing hooks. Verification has two basic steps:
- verifying the cryptographic chain of trust from the peer certificate back to the bundle
- authorizing the peer certificate
Is there utility in tracing each of those events from a debuggability or telemetry perspective? I think the answer is yes?
If so, we'd probably be looking for an addition to the interface as follows:
type Trace struct {
...
AuthenticatePeer func(info AuthenticatePeerInfo) (traceCtx interface{})
AuthenticatedPeer func(traceCtx interface{}, info AuthenticatedPeerInfo)
AuthorizePeer func(info AuthorizePeerInfo) (traceCtx interface{})
AuthorizedPeer func(traceCtx interface{}, info AuthorizedPeerInfo)
}
type AuthenticatePeerInfo struct {
PeerCertificate []*x509.Certificate
}
type AuthenticatedPeerInfo struct {
VerifiedChains [][]*x509.Certificate
Err error
}
type AuthorizePeerInfo struct {
ID spiffeid.ID
VerifiedChains [][]*x509.Certificate
}
type AuthorizedPeerInfo struct {
ID spiffeid.ID
Err error
}
How does that feel?
from go-spiffe.
Related Issues (20)
- Save to disk option HOT 1
- Possible bug in getTLSCertificate where err might not be returned HOT 3
- store serialized JWT token in []byte instead in the JWT-SVID HOT 1
- Convenience pretty-printing json output
- Support for named pipes HOT 17
- Problem with SPIFFE trust domain usage during peer verification HOT 4
- Migration guide from v1 to v2 HOT 4
- Support running tests on CI for each supported minor version of Go HOT 1
- Unable to create TLS connection: spiffetls: cannot create X.509 source: context deadline exceeded HOT 3
- Feature Request: Authorizers combination
- chores: migrate jose from v2 to v3
- Bump google.golang.org/grpc from 1.51.0 to 1.53.0 causes the fake spire server to fail HOT 2
- Example validating JWTs with provided x509 certificate bundle
- Should we add a delegated identity API client to go-spiffe/v2? HOT 1
- Add new ParseRawWithHint() func for X.509-SVID
- Workload API is not working in Windows.
- TestMTLSWebHandshake/client_no_valid_certificate: Error message not equal HOT 3
- WithDefaultX509SVIDPicker / WithDefaultJWTSVIDPicker
- Allow `workloadapi` backoff to be customized
- Support `*slog.Logger` as configured logger HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-spiffe.