-
Notifications
You must be signed in to change notification settings - Fork 16
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
INFOPLAT-1562 dynamic expiring auth headers #974
base: main
Are you sure you want to change the base?
Conversation
- Adds function for signing publickey + timestamp. - Adjusts `BuildAuthHeaders` to take variadic args allowing backwards compatibiilty INFOPLAT-1559 Fixes some lint issues INFOPLAT-1559 Handles edge case of negative timestamps INFOPLAT-1559 Switches to exposing new function - go recommended way to add extend a function - added Config as 2nd arg as opposed to optional args INFOPLAT-1559 Adjusts `authHeaderVersion2` - minor refactor of test INFOPLAT-1559 Tightens time range for test Update pkg/beholder/auth.go Co-authored-by: 4of9 <[email protected]>
- allows for dynamic headers auth tokens to be used in GRPC request headers - auto refreshes the token on interval
…c `AuthHeaders` Need this for migration of existing usage - current users of beholder can still use never verions while using static headers, but can make the switch across to setting `AuthHeaderProvider`
2ed4940
to
e40e8fd
Compare
bit more clear conceptually
protects against concurrent calls of `refresh` INFOPLAT-1560 Makes `refresh` thread safe
…Credentials refresh logic
- uses method for construction
pkg/beholder/client.go
Outdated
otlpmetricgrpc.WithHeaders(config.AuthHeaders), | ||
} | ||
if config.AuthHeaderProvider != nil { | ||
opts = append(opts, otlpmetricgrpc.WithDialOption(grpc.WithPerRPCCredentials(config.AuthHeaderProvider.Credentials()))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems there should be a relationship between otlpmetricgrpc.WithTLSCredentials (line 355, set based on config.InsecureConnection option) and
config.AuthHeaderProvider.Credentials().RequireTransportSecurity
If TLS is enabled AuthHeaderProvider.Credentials().RequireTransportSecurity()should always return true.
Im wondering whats the good way to handle that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets test what happens when RequireTransportSecurity and InsecureConnection mismatch.
pkg/beholder/client.go
Outdated
otlploggrpc.WithHeaders(cfg.AuthHeaders), | ||
} | ||
if cfg.AuthHeaderProvider != nil { | ||
opts = append(opts, otlploggrpc.WithDialOption(grpc.WithPerRPCCredentials(cfg.AuthHeaderProvider.Credentials()))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
if Config.InsecureConnection is `false` we should ensure that we set our `PerRPCCredentials` implementation to return true for `RequireTransportSecurity` While `RequireTransportSecurity` can be set on AuthHeaderProvider initiailzation, its not required, this can lead to a mismatch in configurations, this adds a guard to prevent this from happening
INFOPLAT-1560
What
Allows usage of dynamic auth headers by implementing
grpc.PerRPCCredentials
& setting as aDialOption
on the otel clientWhy
Makes tokens expire, in the case that one is leaked or intercepted.
2
tokens have their timestamp part checkedtime.Now > timestamp > time.Now - serverTTL
Notes
Current users of the client can still configure static headers using the
AuthHeaders
field of beholder clientConfig
. To enable dynamic headers they instead should configureAuthHeaderProvider