-
Notifications
You must be signed in to change notification settings - Fork 72
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
feat: add ssl support to sync service (#1479) #1501
base: main
Are you sure you want to change the base?
feat: add ssl support to sync service (#1479) #1501
Conversation
Signed-off-by: Alexandra Oberaigner <[email protected]>
ced5619
to
80ff0da
Compare
✅ Deploy Preview for polite-licorice-3db33c canceled.
|
✅ Deploy Preview for polite-licorice-3db33c canceled.
|
Signed-off-by: Alexandra Oberaigner <[email protected]>
[QUESTION] can someone help me with a maintainable solution of the certificate generation. Is it okay to run a script at the beginning of the test to generate the files (see Makefile & script)? I figured that just committing these files is not really maintainable since they expire after the on creation specified number of days. What would be good practice? |
Yep, that's fine with me, BUT: I can specify |
should we maybe use the one from the flagd-testbed also within here? |
Yep we could do that. What's the expiry on that one? |
…days expiration period (open-feature#1479) Signed-off-by: Alexandra Oberaigner <[email protected]>
I went the easy route & added a new certificate to the PR that expires in 9999 days as suggested by @toddbaert, let me know if there speaks something against it |
return | ||
} | ||
|
||
serviceClient := syncv1grpc.NewFlagSyncServiceClient(con) |
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.
[INFO] from this line on the test is the same as before
Signed-off-by: Alexandra Oberaigner <[email protected]>
ef58650
to
d97fc8d
Compare
Signed-off-by: Alexandra Oberaigner <[email protected]>
Signed-off-by: Alexandra Oberaigner <[email protected]>
func NewSyncService(cfg SvcConfigurations) (*Service, error) { | ||
l := cfg.Logger | ||
mux, err := NewMux(cfg.Store, cfg.Sources) | ||
if err != nil { | ||
return nil, fmt.Errorf("error initializing multiplexer: %w", err) | ||
} | ||
|
||
server := grpc.NewServer() | ||
var server *grpc.Server | ||
tlsCredentials, err := loadTLSCredentials(cfg.CertPath, cfg.KeyPath) |
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.
As tls.loadX509...(...)
could imply side effects with loading, we should check if CertPath
and KeyPath
are empty upfront, rather relying on the method itself. Specifically as implementation behind this method can change, and we should only invoke it, if the parameters are set.
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.
Thank you. It looks really good, and I love the parameterized test. There is just one thing that we should address, just to be safe.
This PR
Adds SSL support to the flagd sync service
Related Issues
Fixes #1479
How to test
run
make test-flagd