-
Notifications
You must be signed in to change notification settings - Fork 38
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
Issue 479: Addressing Security vulnerabilities with authentication #488
Issue 479: Addressing Security vulnerabilities with authentication #488
Conversation
Signed-off-by: prabhaker24 <[email protected]>
Signed-off-by: prabhaker24 <[email protected]>
…into Issue-479-security-vulnerabilities-with-Authentication
Codecov Report
@@ Coverage Diff @@
## master #488 +/- ##
==========================================
+ Coverage 71.62% 71.77% +0.14%
==========================================
Files 15 15
Lines 3411 3429 +18
==========================================
+ Hits 2443 2461 +18
Misses 865 865
Partials 103 103
Continue to review full report at Codecov.
|
@@ -290,6 +290,12 @@ type AuthenticationParameters struct { | |||
// name of Secret containing Password based Authentication Parameters like username, password and acl | |||
// optional - used only by PasswordAuthHandler for authentication | |||
PasswordAuthSecret string `json:"passwordAuthSecret,omitempty"` | |||
|
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.
For integration purposes, there needs to be a clear description of how to create the two secrets.
I can see through the code the format of the secret is straight forward, with one having one entry which is just a random string; and the other having two entries, one being the same random string, and one being a base64 encoded string of the admin/password, to be used with the password handler.
It won't be obvious to the common dweller though. :)
Having clear couple kubectl commands in the README that show exactly how to generate these 2 secrets is crucial so integrators know how to leverage this welcome enhancement.
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 @sarlaccpit, I have added documentation in the auth section of our documentation.
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, the auth.md is very useful and detailed. It will be crucial information.
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 @sarlaccpit .
Signed-off-by: prabhaker24 <[email protected]>
Signed-off-by: prabhaker24 <[email protected]>
Signed-off-by: prabhaker24 <[email protected]>
…into Issue-479-security-vulnerabilities-with-Authentication
PasswordAuthSecret: "authentication-secret", | ||
Enabled: true, | ||
PasswordAuthSecret: "authentication-secret", | ||
ControllerTokenSecret: "controllerauthsecret", |
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.
For consistency, maybe controllerauthsecret --> controllerauth-secret ?
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 have changed it.
|
||
Below is how we can create secret and expose them as file for Auth related properties:- | ||
|
||
1. Create a File containg `controller.security.auth.delegationToken.signingKey.basis` as `delegationToken.signingKey.basis` which represent the tokensigning key used to connect to the controller: |
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.
Just a nit but I'm not getting what the "basis" suffix means?
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.
Pravega uses this suffix so I tried keeping it the same. In any case this is just a key in a secret so if pravega changes the name for this parameter we can always have the name of the key different.
@@ -290,6 +290,12 @@ type AuthenticationParameters struct { | |||
// name of Secret containing Password based Authentication Parameters like username, password and acl | |||
// optional - used only by PasswordAuthHandler for authentication | |||
PasswordAuthSecret string `json:"passwordAuthSecret,omitempty"` | |||
|
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, the auth.md is very useful and detailed. It will be crucial information.
doc/auth.md
Outdated
|
||
1. Create a File containg `controller.security.auth.delegationToken.signingKey.basis` as `delegationToken.signingKey.basis` which represent the tokensigning key used to connect to the controller: | ||
|
||
Sample encrypted password file: |
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.
Line 89 was maybe a left over from a copy paste from somewhere?
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 have removed it now.
Signed-off-by: prabhaker24 <[email protected]>
Co-authored-by: Christophe Balczunas <[email protected]>
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 good. Just one small misspelled secret name in the tests.
Please insure that Pravega can be deployed without specifying these secrets. So that backward compatibility and smooth adoption of this feature can happen.
I have tested both ways of taking the auth parameters i.e as jvm options and as secret works from the operator side. |
Awesome. Just for completeness, is there a pravega github issue for the leveraging of these secrets? |
link to the issue at pravega side pravega/pravega#5590. |
Change log description
This pr Addresses the Security Vulnerability when Authentication is enabled for pravega.
Purpose of the change
Fixes #479
What the code does
This pr allows the user to specify tokensecrets for both segmentstore and controller and it mounts those secret in a file mounted at /etc/controller-auth-volume for controller and at /etc/ss-auth-volume for segmentstore. Following Params are specified in the secret:-
controller secret is created from a file containing only controller.security.auth.delegationToken.signingKey.basis as delegationToken.signingKey.basis
eg:-
Segmentstore secret contains autoScale.security.auth.token.signingKey.basis as delegationToken.signingKey.basis as well as pravega.client.auth.method ,pravega.client.auth.token and controller.connect.auth.credentials.dynamic are specified as controller.connect.auth.params and are separated by semicolon and in the same order.
eg:-
How to verify it
After pravegacluster is deployed exec into the ss and controller pod and check for the presence of the respective files at the above-specified location for both ss and controller containing the values given by there secret respectively.