-
Notifications
You must be signed in to change notification settings - Fork 6
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
PB-6687 :: Placing PX secret in nfsrestore job spec #360
Conversation
pkg/drivers/nfsrestore/nfsrestore.go
Outdated
@@ -248,6 +248,11 @@ func jobForRestoreResource( | |||
logrus.Infof("failed to get the px service name and namespace: %v", err) | |||
return nil, fmt.Errorf("failed to get the px service name and namespace: %v", err) | |||
} | |||
// |
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.
nit: remove this blank comment line.. or add some story here describing what scenario we need this secret fetching
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.
This review is generated on the latest stork. Can you please rebase with master and then send PR. There are stale changes.
Also if there is vendor changes. Best to send it as seperate PR to have only the necessary changes show up in commit.
pkg/drivers/nfsrestore/nfsrestore.go
Outdated
Value: pxSecretIssuer, | ||
}) | ||
} | ||
if len(pxSecretKey) != 0{ |
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.
By setting the secretKey as ENV would make this visible to every one who has even pod view. If I understand from stork. The stork deployment only references the k8s secret reference name but the secretKey is embedded in the k8s secret. But here we are passing as job pod env. I am not sure if this becomes a security vulnerability.
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.
By setting the secretKey as ENV would make this visible to every one who has even pod view. If I understand from stork. The stork deployment only references the k8s secret reference name but the secretKey is embedded in the k8s secret. But here we are passing as job pod env. I am not sure if this becomes a security vulnerability.
This is a nfs restore job so once completed it gets deleted. Also stork can use that in such a manner because it resides in same namespace as of portworx but nfs restore will start in some other ns where that secret will not be present hence passing that as ENV.
Also anyone having job pod view right now can view these access keys from stork too as in pod it is an ENV variable only
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.
@vikasit12 As discussed, let us please create the secret in the stork code ( Resourceexport reconciler code) and pass only the secret name and namespace similar to other secret like cred/cert/image registry secret.
…Enabled Signed-off-by: Vikas Kumar <[email protected]>
What this PR does / why we need it:
This PR gets secret env from stork deploy used in nfs restore of secured portworx volumes. The access key retrieved is passed as env variable in nfs restore job to complete nfs restore
Which issue(s) this PR fixes (optional)
Closes #PB-6687
Special notes for your reviewer:
Test Cases combination performed:
Backup and restore