squakez commented on pull request #1912:
URL: https://github.com/apache/camel-k/pull/1912#issuecomment-762201031


   > > I am making the development to exec into the kamel operator, however I 
am thinking about the possible security concerns. Should we allow the CLI to 
run an arbitrary command on the operator running pod? I am not sure it's a good 
choice.
   > 
   > It has indeed security concerns, and UX as a result. For that approach to 
work, the end-user has to have the permission to run the `exec` request. This 
is managed by Kubernetes RBAC, so the end-user has to be authorised. And then, 
he/she can run arbitrary command.
   > 
   > Other options that I can think of would be:
   > 
   >     * Expose a `version` endpoint: the operator already expose HTTP 
endpoints for health and monitoring
   > 
   >     * Simply add an annotation to the deployment with the version 
information
   > 
   > 
   > While the `exec` approach is more correct, these alternatives are probably 
less involved security and UX wise.
   > 
   > WDYT?
   
   I was exactly looking at the possibility to expose a `version` endpoint as 
that is the approach taken by `kubectl`:
   ```
   $ kubectl version -v 9
   I0118 12:49:13.727726  323730 loader.go:375] Config loaded from file:  
/home/squake/.kube/config
   I0118 12:49:13.728448  323730 round_trippers.go:423] curl -k -v -XGET  -H 
"User-Agent: kubectl/v1.19.0 (linux/amd64) kubernetes/e199641" -H "Accept: 
application/json, */*" 'https://172.17.0.2:8443/version?timeout=32s'
   I0118 12:49:13.728469  323730 cert_rotation.go:137] Starting client 
certificate rotation controller
   I0118 12:49:13.734369  323730 round_trippers.go:443] GET 
https://172.17.0.2:8443/version?timeout=32s 200 OK in 5 milliseconds
   I0118 12:49:13.734385  323730 round_trippers.go:449] Response Headers:
   I0118 12:49:13.734390  323730 round_trippers.go:452]     Content-Length: 261
   I0118 12:49:13.734394  323730 round_trippers.go:452]     Date: Mon, 18 Jan 
2021 11:49:13 GMT
   I0118 12:49:13.734399  323730 round_trippers.go:452]     Cache-Control: 
no-cache, private
   I0118 12:49:13.734402  323730 round_trippers.go:452]     Content-Type: 
application/json
   I0118 12:49:13.735425  323730 request.go:1097] Response Body: {
     "major": "1",
     "minor": "19",
     "gitVersion": "v1.19.2",
     "gitCommit": "f5743093fd1c663cb0cbc89748f730662345d44d",
     "gitTreeState": "clean",
     "buildDate": "2020-09-16T13:32:58Z",
     "goVersion": "go1.15",
     "compiler": "gc",
     "platform": "linux/amd64"
   }
   Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", 
GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", 
BuildDate:"2020-08-26T14:30:33Z", GoVersion:"go1.15", Compiler:"gc", 
Platform:"linux/amd64"}
   Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", 
GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", 
BuildDate:"2020-09-16T13:32:58Z", GoVersion:"go1.15", Compiler:"gc", 
Platform:"linux/amd64"}
   ```
   I see this more appropriate and we can include any further info that we will 
retain useful in the future (plus gitCommit and such). Can you point me at the 
code where we expose health and monitoring please? I can work to include this 
new endpoint. The only drawback is that there is no way to make this change 
backward compatible and will work only with CLI/operators installed from newer 
versions.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to