specification Auth definition being able to use $SECRET to avoid hardcoded passwords in file

Auth definition being able to use $SECRET to avoid hardcoded passwords in file

Open fjtirado opened this issue 1 year ago • 11 comments

What would you like to be added:

In Auth Definition section, explicitly mention that users, rather than hardcode the password string, can use $SECRET (afaik, $SECRET usage is restricted to expressions)

Why is this needed: To avoid hardcoding passwords, either in the workflow file or the json/yaml file, referenced from the workflow file, containing auth definitions.

Sep 07 '22 07:09 fjtirado

@fjtirado The spec supports using a secret name as an authDef properties value.

So, instead of doing:

auth:
  - name: MyBasicAuth
    scheme: basic
    properties:
      username: myUserName
      password: ********

You can do:

auth:
  - name: MyBasicAuth
    scheme: basic
    properties: 'mybasicauthsecret.yaml'

The spec should however indeed specify that any and all fields of the properties can be assigned runtime expressions.

auth:
  - name: MyBasicAuth
    scheme: basic
    properties:
      username: '${ .user.email }'
      password: '${ $SECRET.password }'

Sep 07 '22 09:09 cdavernas

@cdavernas
Just for verifying we have the same understanding Which will be the content of mybasicauthsecret.yaml?

Sep 07 '22 09:09 fjtirado

@fjtirado It is expected to match 1:1 on the chosen scheme's properties:

{
   "username": "myUserName",
   "password": "MyPassword"
}

Sep 07 '22 09:09 cdavernas

@cdavernas Ok, the problem is that, even with the reference file, the password will still be visible, so the implementation of the spec needs to support $SECRET replacement also there. This is not 100% clear (I mean is currently open to intepretation) Anyway, we both agree it should be supported ;)

Sep 07 '22 10:09 fjtirado

Ok, the problem is that, even with the reference file the password will still be visible

I'm not sure I understand. It won't be visible in the definition, as the secret file will be mounted by the runtime. You can review the content of the secret file if you have access to it, but not through the workflow.

Sep 07 '22 10:09 cdavernas

@cdavernas I mean the reference yaml file will still have the password visible. I agree it wont be visible anymore in the flow, of course ;)

Sep 07 '22 11:09 fjtirado

dont think sw mandates it to be a json file its uri that in end can point to a secrets/token provider service of your choice. its as mentioned up to runtime to dowhat it wants.

Sep 07 '22 11:09 tsurdilo

ok, focusing on the inline approach, what about explicitly establishing the $SECRET is supported for auth Right now, we have Secrets can be used only in Workflow expressions by referencing them via the $SECRETS variable. Runtimes must make $SECRETS available to expressions as a predefined variable. Which is fine, except that $SECRET also makes sense for password property of auth properties.

Sep 07 '22 12:09 fjtirado

@fjtirado Yes, like I said I think you are right, we should indicate that runtime expressions should be supported for auth properties, too ;)

Sep 07 '22 12:09 cdavernas

Opened PR on spec to allow this https://github.com/serverlessworkflow/specification/pull/669

Sep 07 '22 16:09 fjtirado

@fjtirado Yes, like I said I think you are right, we should indicate that runtime expressions should be supported for auth properties, too ;)

@cdavernas you cannot use runtime expressions for auth if auth is used for downloading an uri inside an operation. Problem here is the change we did to state that auth definition might be used both for downloading the spec and for invoking the spec funciton. This should have been two separacte structures (or same structure but with different behaviour depending of who is referencing it). The one for downloading might not contain expression (just hardcoded and $SECRET) and the one for invoking operations of course might contain runtime expressions

Sep 07 '22 17:09 fjtirado