Allow Larky Scripts that Are At Last Partially Opaque to the Customer

[rahul-x-verma]

Problem or feature statement

Some times, for security reasons, we do not want the customer to see part of a route configuration - for example, if the route requires using a key that the customer should not see, we will want to hardcode the key into the configuration in a way that the customer can't see even the VGS alias for the key. In FCOs, this can be accomplished by putting the key alias in the FCO definition, because the route YAML will then just contain the FCO name.

Advised solution

Being able to encrypt entire Larky scripts in a way that the proxy can decrypt and execute them. Alternatively, being able to encrypt VGS aliases in a way that only the proxy executing a script can see the underlying value i.e. the customer can't take the alias out of the route configuration and feed it to a route that reveals it back to themselves.

Testing scenarios

• Create a route that has a VGS alias in its Larky definition, and verify a) The route can use the underlying data in the VGS vault b) There is no way to determine the VGS alias from the Larky configuration

[mjallday]

what's wrong with using fco for this purpose and wrapping the larky code inside an fco?

[rahul-x-verma]

The FCO work fine, it just would be nice to not have to go through the FCO process for future customers.