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

Issue 479: Addressing Security vulnerabilities with authentication #488

Merged

Conversation

Prabhaker24
Copy link
Contributor

@Prabhaker24 Prabhaker24 commented Dec 18, 2020

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:-

  1. controller.security.auth.delegationToken.signingKey.basis
  2. autoScale.security.auth.token.signingKey.basis
  3. pravega.client.auth.token
  4. pravega.client.auth.method
  5. controller.connect.auth.credentials.dynamic

controller secret is created from a file containing only controller.security.auth.delegationToken.signingKey.basis as delegationToken.signingKey.basis
eg:-

delegationToken.signingKey.basis: {secret}

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:-

delegationToken.signingKey.basis: {secret}
controller.connect.auth.params: {method};{token};{dynamic}

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.

prabhaker24 added 3 commits December 4, 2020 15:27
Signed-off-by: prabhaker24 <[email protected]>
…into Issue-479-security-vulnerabilities-with-Authentication
@codecov-io
Copy link

codecov-io commented Dec 18, 2020

Codecov Report

Merging #488 (4333ee9) into master (e6dc8e3) will increase coverage by 0.14%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            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              
Impacted Files Coverage Δ
pkg/apis/pravega/v1beta1/pravegacluster_types.go 25.36% <ø> (ø)
pkg/controller/pravega/pravega_controller.go 100.00% <100.00%> (ø)
pkg/controller/pravega/pravega_segmentstore.go 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e6dc8e3...4333ee9. Read the comment docs.

@@ -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"`

Copy link
Contributor

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.

Copy link
Contributor Author

@Prabhaker24 Prabhaker24 Jan 16, 2021

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.

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @sarlaccpit .

prabhaker24 added 4 commits January 13, 2021 10:23
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",
Copy link
Contributor

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 ?

Copy link
Contributor Author

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:
Copy link
Contributor

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?

Copy link
Contributor Author

@Prabhaker24 Prabhaker24 Jan 25, 2021

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"`

Copy link
Contributor

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:
Copy link
Contributor

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?

Copy link
Contributor Author

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]>
Copy link
Contributor

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

@Prabhaker24
Copy link
Contributor Author

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.

@sarlaccpit
Copy link
Contributor

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?

@Prabhaker24
Copy link
Contributor Author

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.

@anishakj anishakj merged commit 9d15bf1 into master Jan 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

security vulnerabilities with Authentication should be removed from the pravega code
4 participants