-
Notifications
You must be signed in to change notification settings - Fork 61
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
Support sasl kafka endpoint options in Fastly CLI #161
Support sasl kafka endpoint options in Fastly CLI #161
Conversation
@kellymclaughlin I haven't reviewed yet, but just noting I think this will require us to update the go-fastly version in the Go module to get the latest version with these new fields, right? |
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.
Thanks for the contribution @kellymclaughlin, looking good overall just want to clean up some of the flag types.
Also made me realise that Kingpin really needs a flag.RequiredIfSet(*otherFlag)
flag clause to decorate flag dependencies to avoid us having to write the validation logic for these relationships.
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.
I agree with @phamann's comments, but also added a couple comments of my own.
Otherwise, things look good to me.
pkg/logging/kafka/create.go
Outdated
} | ||
} | ||
|
||
if !c.UseSASL.Value && (c.AuthMethod.Value != "" || c.User.Value != "" || c.Password.Value != "") { |
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.
Disregard the following, but it was a thought that crossed my mind.
I based my final judgement on how cat
and gcloud
handle extraneous flags.
thought - Is this block really necessary? In other words isn't this safe to just accept, but not do anything with these values since the values are only set in the above block?
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.
Good question. It's not necessary. The reason I added this was trying avoid unexpected results and unnecessary debugging. My reasoning was if a user gives the auth method, username, or password they probably meant to enable SASL and by accepting the invalid set of options we've possibly added to the confusion. The hope is by enforcing this at creation time we're saving them and possibly ourselves some time. Happy to remove it though if you think it's not worth it.
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 is probably worth giving the user feedback when the options they used make no sense. My $0.02 it should stay. The more Go Way to do it would be to move this invalid case as far up in the function as possible.
}, | ||
}, | ||
{ | ||
name: "verify disabling SASL", |
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.
We may be able to disregard the following because the CLI will require that credentials always be supplied when SASL is enabled, but we should probably confirm that you can't enable, disable and re-renabled without supplying credentials in the API.
TL;DR - we should ensure that when we disable SASL, we removed the stored SASL creds i.e., make sure these zero values make it through to the backend.
Thanks for including this test!! It got me thinking...
I just want someone else to confirm my thoughts and that the following is true on the following:
- enable SASL (i.e., send credentials to Fastly)
- disable SASL
- This will "delete" the SASL credentials, right?
- re-enable SASL, but don't supply credentials.
This may require us to confirm in go-fastly that sending empty string values to go-fastly will actually make it through to the Fastly backend.
Basically, I want to ensure that we don't have a possible security issue where if SASL was ever enabled, it couldn't be disabled and then re-enabled without 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.
Agreed, the code to ensure that we remove the stored creds is here. Right now the API doesn't establish a relationship among any of the Kafka configuration fields and I reflected that in my go-fastly
changes. I think ideally we'd implement this logic once in the API versus in each consumer, but for now I wanted to deal with it here until I worked out the best way to deal with it more generally.
* Use NegatableBoolVar instead of two explicit flags * Use EnumVar for --auth-method to restrict valid input values * Remove some unnecessary test formatting * Remove obsolete test cases
Thanks for looking over this @phamann! I just came across the As far as Kingpin, I would have definitely enjoyed a |
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.
Some small nits related to https://github.com/golang/go/wiki/CodeReviewComments#indent-error-flow
pkg/logging/kafka/create.go
Outdated
} | ||
} | ||
|
||
if !c.UseSASL.Value && (c.AuthMethod.Value != "" || c.User.Value != "" || c.Password.Value != "") { |
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 is probably worth giving the user feedback when the options they used make no sense. My $0.02 it should stay. The more Go Way to do it would be to move this invalid case as far up in the function as possible.
…lin/cli into kelly/add-kafka-sasl-fields
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.
Thanks @kellymclaughlin. This is looking good now. Just some edits to make the flag descriptions consistent with the rest of the project. You'll need to regenerate the app help for the tests to pass once accepted. Then we're good to go.
Remove periods from flag descriptions Co-authored-by: Patrick Hamann <patrick@fastly.com>
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.
LGTM 🎉
Thanks for the contribution @kellymclaughlin and apologies its taken so long to get over the line.
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.
One very minor comment, also it would be good to have these new fields documented. I've left a comment on the most recent jira ticket here for reference: here
go.sum
Outdated
@@ -32,6 +32,8 @@ github.com/emirpasic/gods v1.12.0 h1:QAUIPSaCu4G+POclxeqb3F+WPpdKqFGlw36+yOzGlrg | |||
github.com/emirpasic/gods v1.12.0/go.mod h1:YfzfFFoVP/catgzJb4IKIqXjX78Ha8FMSDh3ymbK86o= | |||
github.com/fastly/go-fastly v1.16.0 h1:RMHvkzZ52J60+jSPK+6BLodIsx4OBlaoB18XmL7C0+Y= | |||
github.com/fastly/go-fastly v1.16.0/go.mod h1:jILbTQnU/K/7XHQNzQWd1O7hbXIcp6dKrxfRWqU6xfk= |
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.
@kellymclaughlin I just pulled your branch and ran make all
and found that the go.sum
was updated for me to remove the v1.16.0 dependency. Are you OK to update this PR with that change?
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.
@Integralist Ok, I've pushed that change.
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.
Thanks @kellymclaughlin - just to let you know that Patrick and I are still chipping away at the Go-Fastly v2 merge/release (things got complicated 😬) but we expect to have it finished today.
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 looks like something has changed in the last day or so on the Github side with setting environment variables for the CI actions and it's now causing the checks to fail. Let me know if you would like me to try to run that down for this PR.
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.
Looks like there is an |
Third time's a charm, but got the CI checks happy again. |
Add the following options to the Kafka logging subcommands in order to support SASL:
parse-log-kevvals
- Indicates the log format should be parsed as key-value pairsmax-batch-size
- The maximum size of a log batch in bytesauth-method
- one of:plain
,scram-sha256
,scram-sha512
username
- Username for authenticationpassword
- Password for authentication