[WIP]process-state: filter out additional contents from state downloads

[amithkb]

• Currently _main.json has additional data like defaultTaskVariables which might contain sensitive data which will be open to access for all when download state of the process.
• Soln: add filters to restrict only non sensitive fields to such state downloads

[ibodrov]

JFYI, Downloading process state is guarded by

concord/server/impl/src/main/java/com/walmartlabs/concord/server/process/ProcessResource.java

Line 966 in aebe1f5

private void assertProcessAccess(ProcessEntry pe, String downloadEntity) {

Also, it should be possible to put expressions into defailtTaskVars that fetch the sensitive data (from secrets). This way you'll get explicit control over who can access it and the audit log.

[amithkb]

JFYI, Downloading process state is guarded by

concord/server/impl/src/main/java/com/walmartlabs/concord/server/process/ProcessResource.java

Line 966 in aebe1f5

private void assertProcessAccess(ProcessEntry pe, String downloadEntity) {

Yes. The current usage is like global public project is present, where end user process runs with end-user Ids. But the requirement is, need to filter certain content even from the process initiator.

Also, it should be possible to put expressions into defailtTaskVars that fetch the sensitive data (from secrets). This way you'll get explicit control over who can access it and the audit log.

defaultTaskVariables are injected through policies which is available only inside the task

[ibodrov]

I don't see how filtering _main.json would help in this case -- the process initiator will have the ability to get the default vars anyway by just printing them out from within the flow?

I didn't test it, but perhaps we can put something like ${crypto.exportAsString(...)} into the policy instead of the actual value? So it is not passed in _main.json but rather fetched at runtime?

[ibodrov]

Something like

configuration:
  runtime: "concord-v2"

flows:
  default:
    - script: js
      body: |
        let vars = context.processConfiguration().defaultTaskVariables()
        print(vars)

All I am saying is that defaultTaskVars is not a good mechanism to pass secrets.

[amithkb]

Yeah. Requirement is directly inject the secrets inside the task only and users should not be able to print it or use it outside the task for any other purpose. Here secrets are maintained by admins. Any good way to acheive this?

[ibodrov]

A better way is to change tasks to accept secret references (orgName/secretName) instead of secret values. And then fetch the secret values directly in tasks at runtime. For example, that is how Ansible tasks fetches the keys, if I remember it correctly.

And then secret references can be defaultTaskVars.

[amithkb]

A better way is to change tasks to accept secret references (orgName/secretName) instead of secret values. And then fetch the secret values directly in tasks at runtime. For example, that is how Ansible tasks fetches the keys, if I remember it correctly.

And then secret references can be defaultTaskVars.

But Secret is public and anyone can access it outside the task as well. For example slack token which has to be used inside the slack task provided by concord admin only