Secrets

[tetron]

No description provided.

[mr-c]

Suggested change

	* false (same as null)
	* true (parameter is secret)
	* `false` (same as null)
	* `true` (parameter is secret)

[mr-c]

Suggested change

	If the value of `secret` is a string, this is a lookup key to
	be used to fetch a secret value from the workflow platform
	If the value of `secret` is a string, this is a lookup key that can
	be used to fetch a secret value from the workflow platform

[mr-c]

Suggested change

	parameter must only consist of `string`, `array<string>`, or
	parameter must only consist of `string`, `string[]`, or

[tetron]

From discussion, should limit to only resolving the top level.

Marius: maybe this should be called "protected".

[tetron]

Another idea:

Instead of putting the key in the workflow inputs

inputs:
  inp2:
    type: string
    secret: AWSPASS

Specify the secret in the input document:

inputs:
  inp2:
    type: string
    sensitive: true

inp2:
  class: Secret
  secretKey: urn:aws-secret-12345

inp2: IlikeMonkeys

inp2: {$include: ~/.config/my_password}

Use default to achieve the behavior of referencing secrets from the workflow:

inputs:
  inp2:
    type: string
    sensitive: true
    default:
      class: Secret
      secretKey: urn:aws-secret-54321

[tom-tan]

I have a question about secret.

How to behave when the secret strings are written in files?
For me, the written files must be still treated as secret: that is, we need secret files as well as secret strings. Once we introduce a concept of secret files and secret strings, the spec may be simpler: a file that contains secret strings is a secret file, and a (sub) string that is read from a secret file is a secret string.

[tetron]

New idea. Get rid of "confidential" and introduce "SecretText" record that is passed through and dereferenced to get "plaintext" only when needed.

inputs:
  inp1: SecretText

inp1:
  class: SecretText
  secretId: urn:id-12345

inp1:
  class: SecretText
  secretId: urn:id-12345
  plaintext: IlikeMonkeys