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

NETOBSERV-974 Add SASL support #112

Merged
merged 2 commits into from
May 10, 2023
Merged

Conversation

jotak
Copy link
Member

@jotak jotak commented Apr 14, 2023

SASL is a common protocol used for authentication with Kafka, that strimzi supports.
This PR adds support to SASL configuration when the agent is used with Kafka. To enable it, set KAFKA_ENABLE_SASL to true. The path to clientID (KAFKA_SASL_CLIENT_ID_PATH) and to a Secret (KAFKA_SASL_CLIENT_SECRET_PATH) must be configured. KAFKA_SASL_TYPE can be either "plain" or "scramSHA512".

@jotak
Copy link
Member Author

jotak commented Apr 14, 2023

linter fails due to cyclo: taking this opportunity to ask you, @msherif1234 @praveingk what's your thoughts on this. Personally I hate this linter metric, I think a long and dumb function is better and more readable than 10 small and dumb functions. Especially when it doesn't make code more reused. So if it was just me I would just raise the golangci-lint cyclop max value to make linter pass. But as you're more actively contributing to this repo, I'll follow what you can suggest :-)
(I can also defintely create new dumb functions to make linter happier)

// KafkaSASLClientIDPath is the path to the client ID (username) for SASL auth
KafkaSASLClientIDPath string `env:"KAFKA_SASL_CLIENT_ID_PATH"`
// KafkaSASLClientSecretPath is the path to the client secret (password) for SASL auth
KafkaSASLClientSecretPath string `env:"KAFKA_SASL_CLIENT_SECRET_PATH"`
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a default value ?

Copy link
Member Author

Choose a reason for hiding this comment

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

There's no default (or in fact, the default is SASL being disabled so these variable are unused). It's the same with the TLS cert path config: as soon as TLS / SASL is enabled, these variables must be configured - but the default still works as they're disabled by default.

default:
return nil, fmt.Errorf("unknown SASL type: %s", cfg.KafkaSASLType)
}
if err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

there is no need for this block since u already return on err

Copy link
Member Author

Choose a reason for hiding this comment

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

actually, the line above was setting an error; I modified this part so it's more visible that an error might be produced

pkg/agent/tls.go Outdated
@@ -35,5 +35,5 @@ func buildTLSConfig(cfg *Config) (*tls.Config, error) {
}
return tlsConfig, nil
Copy link
Contributor

Choose a reason for hiding this comment

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

u won't need this return then ?

@msherif1234
Copy link
Contributor

linter fails due to cyclo: taking this opportunity to ask you, @msherif1234 @praveingk what's your thoughts on this. Personally I hate this linter metric, I think a long and dumb function is better and more readable than 10 small and dumb functions. Especially when it doesn't make code more reused. So if it was just me I would just raise the golangci-lint cyclop max value to make linter pass. But as you're more actively contributing to this repo, I'll follow what you can suggest :-) (I can also defintely create new dumb functions to make linter happier)

I would just creating 3 functions one for grpc , kafka and one for ipfix that take protocol as arg, in general even though the function is plain straight fwd but its not good practice having lengthy functions IMO but again this more of nit preference I will go with whatever the rest agree with

@jotak
Copy link
Member Author

jotak commented May 10, 2023

@msherif1234 I did what you suggested about splitting the big function

@codecov
Copy link

codecov bot commented May 10, 2023

Codecov Report

Merging #112 (8480e36) into main (3f192b3) will decrease coverage by 0.57%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #112      +/-   ##
==========================================
- Coverage   41.80%   41.24%   -0.57%     
==========================================
  Files          30       31       +1     
  Lines        2050     2078      +28     
==========================================
  Hits          857      857              
- Misses       1155     1183      +28     
  Partials       38       38              
Flag Coverage Δ
unittests 41.24% <0.00%> (-0.57%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
pkg/agent/agent.go 39.20% <0.00%> (-0.58%) ⬇️
pkg/agent/sasl.go 0.00% <0.00%> (ø)
pkg/agent/tls.go 0.00% <0.00%> (ø)

@msherif1234
Copy link
Contributor

/lgtm

@msherif1234
Copy link
Contributor

pls add more context to the PR description so we can know what this PR did for reference Thanks!!

@jotak jotak added no-doc This PR doesn't require documentation change on the NetObserv operator no-qe This PR doesn't necessitate QE approval labels May 10, 2023
@jotak
Copy link
Member Author

jotak commented May 10, 2023

Thanks @msherif1234

/approve

@openshift-ci
Copy link

openshift-ci bot commented May 10, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jotak

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jotak
Copy link
Member Author

jotak commented May 10, 2023

Just to clarify, I set no-doc/QE labels as it has no impact downstream unless it's configured from the operator - there's an epic for that which isn't planned yet.

@openshift-merge-robot openshift-merge-robot merged commit 4272333 into netobserv:main May 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved lgtm no-doc This PR doesn't require documentation change on the NetObserv operator no-qe This PR doesn't necessitate QE approval
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants