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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support sasl kafka endpoint options in Fastly CLI #161

Merged
merged 16 commits into from
Nov 19, 2020

Conversation

kellymclaughlin
Copy link
Contributor

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 pairs
  • max-batch-size - The maximum size of a log batch in bytes
  • auth-method - one of: plain, scram-sha256, scram-sha512
  • username - Username for authentication
  • password - Password for authentication

@phamann phamann requested a review from mccurdyc October 27, 2020 11:40
@mccurdyc
Copy link
Collaborator

@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?

fastly/go-fastly#227

Copy link
Member

@phamann phamann left a 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.

pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
@phamann phamann added the enhancement New feature or request label Oct 29, 2020
Copy link
Collaborator

@mccurdyc mccurdyc left a 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.

}
}

if !c.UseSASL.Value && (c.AuthMethod.Value != "" || c.User.Value != "" || c.Password.Value != "") {
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

pkg/logging/kafka/kafka_integration_test.go Outdated Show resolved Hide resolved
},
},
{
name: "verify disabling SASL",
Copy link
Collaborator

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:

  1. enable SASL (i.e., send credentials to Fastly)
  2. disable SASL
    • This will "delete" the SASL credentials, right?
  3. 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.

Copy link
Contributor Author

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.

pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
* 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
@kellymclaughlin
Copy link
Contributor Author

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.

Thanks for looking over this @phamann! I just came across the NegatableBool yesterday evening myself and I didn't know about EnumVar. I've made those changes.

As far as Kingpin, I would have definitely enjoyed a RequiredIfSet option. I also found the builtin validation stuff in the library not usable in our context which is too bad. I also noticed we're relying on the v3-unstable branch of Kingpin and I see that the author has ceased contributing to the library and has created an entirely new library for args parsing. This is my first foray into the cli code, but I wonder if there has been any consideration of moving to a new args parsing library that is more actively supported and offer us some better features? If there is ever discussion of that I'd be happy to be involved and be part of a divide and conquer effort to get it done.

Copy link
Contributor

@jaredmorrow jaredmorrow left a comment

Choose a reason for hiding this comment

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

}
}

if !c.UseSASL.Value && (c.AuthMethod.Value != "" || c.User.Value != "" || c.Password.Value != "") {
Copy link
Contributor

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.

pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
Copy link
Member

@phamann phamann left a 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.

pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/create.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
pkg/logging/kafka/update.go Outdated Show resolved Hide resolved
kellymclaughlin and others added 2 commits November 10, 2020 08:33
Remove periods from flag descriptions

Co-authored-by: Patrick Hamann <patrick@fastly.com>
Copy link
Member

@phamann phamann left a 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.

Copy link
Collaborator

@Integralist Integralist left a 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

pkg/app/run_test.go Show resolved Hide resolved
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=
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@Integralist
Copy link
Collaborator

Looks like there is an add-path used as well somewhere and that I believe also needs to use the new github environment files? https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-commands-for-github-actions#environment-files

@kellymclaughlin
Copy link
Contributor Author

Third time's a charm, but got the CI checks happy again.

@Integralist Integralist merged commit e9802d1 into fastly:master Nov 19, 2020
@kellymclaughlin kellymclaughlin deleted the kelly/add-kafka-sasl-fields branch November 19, 2020 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants