KRV-6540: jq substitute when importing tokens during authorization deployment #301
Conversation
donatwork
requested review from
gallacher,
mjsdell,
prablr79,
rajendraindukuri,
rsedlock1958 and
shanmydell
as code owners
|
|
||
| The following CSM Authorization components are installed in the specified namespace: | ||
| - proxy-service, which forwards requests from the CSI Driver to the backend storage array | ||
| - tenant-service, which configures tenants, role bindings, and generates JSON Web Tokens | ||
| - role-service, which configures roles for tenants to be bound to | ||
| - storage-service, which configures backend storage arrays for the proxy-server to foward requests to | ||
|
|
||
| The folloiwng third-party components are installed in the specified namespace: | ||
| The following third-party components are installed in the specified namespace: |
| @@ -253,7 +259,7 @@ Create the karavi-authorization-config secret using the following command: | |||
| `kubectl -n [CSI_DRIVER_NAMESPACE] create secret generic proxy-server-root-certificate --from-file=rootCertificate.pem=/path/to/rootCA -o yaml --dry-run=client | kubectl apply -f -` | |||
|
|
|||
|
|
|||
| >__Note__: Follow the steps below for additional configurations to one or more of the supported CSI drivers. | |||
| >__Note__: Follow the steps below for additional configurations to one or more of the supported CSI drivers. | |||
There was a problem hiding this comment.
Change "the steps below: to "these steps"
| @@ -231,6 +231,11 @@ data: | |||
|
|
|||
| This secret must be applied in the driver namespace. Continue reading the next section for configuring the driver to use CSM Authorization. | |||
|
|
|||
| >__Note__: | |||
There was a problem hiding this comment.
Do we need this note about jq if we're removing the jq dependency?
There was a problem hiding this comment.
Using jq should be the preferred approach as it is meant to be used for structured data verses some Unix commands to parse text. Parsing text is fragile. If I make the command more robust then it gets more complex. We should just stick with jq.
I'm not a fan of making doc changes to add substitutions as we should have documented the sed commands in the original issue and closed. Most admins should already have some idea of what they can use as an alternative, even manual copy and pasting, especially if they are managing a k8s cluster in a Linux environment.
There was a problem hiding this comment.
Should we keep the original command with jq as an option for those that have jq in their environment, as well as add this new command with sed?
There was a problem hiding this comment.
What if we had a common section where we cover the tools that are not normally in a distribution. I can see the RPM locations for the selinux as another use case.
There was a problem hiding this comment.
We could change to use a more robust Python 3 option. It is more likely that Python 3 is bundled with the distribution.
| python3 -c "import json,sys; print(json.load(sys.stdin)['Token'])"
There was a problem hiding this comment.
OK I changed to using Python. More robust than sed at a smaller risk of changes to the output.
|
Please link to the github issue mentioned in this PR. Thanks! |
|
I need one more code owner to approve. |
|
Need to resubmit with signed commits. |
Description
Add alternative method to extract the token and convert to YAML format. Added note in both Helm and RPM deployment sections. There are more than one way to do this but felt that sed is in all major distributions and not everyone may use Python's json module which is another option I thought about.
There were some trailing whitespace that got removed due to my editor's save actions. You may want to ignore whitespace when viewing the diffs.
Testing
GitHub Issues
List the GitHub issues impacted by this PR:
Checklist: