Don't include probeToken in responses if user doesn't have pt.view permission

[foot]

☂️ issue: #2125

[foot]

Right, so we can easily filter this out of responses from users service, but scope exposes the token in command line args etc. =/

[foot]

I guess permission on namespaces would solve this...

[bboreham]

We could set up the token as a Secret for the scope agent? (in launch-generator)

[foot]

Good thought!

Atm the fluxd etc still receives the secret on the command line. Could the process talk directly to k8s to get the secret?

[foot]

Other hacky solutions:

• Have a (middleware?) layer that does a string search / replace on any encoded JSON response just before its sends back to the client. scope launch --forbidden-strings=abcafe123
• Have a similar layer in authfe which does a string search/replace on the stream as it goes back to the browser.

[foot]

Hacks continued

• Expand out the authfe auth middleware so it starts understanding scope json structure and doing a more fine grained sanitisation pass. Which could allow us to explore doing namespace filtering etc in the future... (graphqqqqqql?)

[foot]

Have a similar layer in authfe which does a string search/replace on the stream as it goes back to the browser.

If this was very general it would be pretty cool if you had permissions to exec/attach but not to view probe token. Then we'd also filter the WS terminal stream.

$ ps aux | grep fluxd
fluxd 100 344 ./flux --token=MISSINGPERMISSIONS

[foot]

Then we'd also filter the WS terminal stream.

Which you could hack by getting the first half and then the 2nd half of the token somehow... we should have warnings about exec/attach permissions, that is essentially giving view-token and thus admin rights.

[foot]

Ooops didn't mean to close this.

[foot]

In light of weaveworks/scope#2106 (scope can expose passwords and tokens for all your services) we should probably include a permission to use scope at all?

[rade]

we should probably include a permission to use scope at all?

No. If we do anything here it should be a permission that controls whether a user can see env vars, command line args, etc. This is something that would be enforced in the scope app rather than probe, since we do still want probes to send all info as some users (e.g.) need to be able to see it.

[foot]

Cool. This feels like a good way forward then.

• Some header / query params appended by authfe hideProcessArgs=1&hideEnvVars=1 depending on permissions.
• Scope does per request filtering on process.args && env.var.

[foot]

Probe gives a good indication about where to filter w/ noEnvironmentVariables && noCommandLineArguments

[fbarl]

Scope report censoring PR weaveworks/scope#3571 implements the Scope part of #2477 (comment).

After that one's done and merged, we can add a small conditional wrapper in authfe to wrap up the Scope part of this issue as @foot suggested.