!var:directory

[OJFord]

Is your feature request related to a problem? Please describe

Essentially the same problem !var:file solves (which is fantastic) but for a directory.

Describe the solution you would like

Whether this works (and how) is probably provider-specific, but I'm familiar with (go)pass, which already uses a directory structure, for example my GitHub password might be in pass show passwords/web/github.

Using the same example, I'd like to be able to summon --yaml 'WEB_PASSWORDS: !var:dir passwords/web' ls '$WEB_PASSWORDS':

example github microsoft

Describe alternatives you have considered

I suppose the only alternative is multiple vars and a wrapper script, which would need updating every time the (number or name of) files within the directory changed.

Additional context

[sgnn7]

Hey @OJFord , Thank you for using Summon - we always love to hear from our users!

As to your issue here, I do understand your need here but sadly I think the difficulty of implementing such a feature is beyond reasonable viability within the current architecture.

The reason I say all this is due to the interaction boundary between summon and the provider which at the current time is a plaintext data exchange:

• summon => (variable ID via stdin) => <provider>
• <provider> => (variable value via stdout) => summon

Since the plaintext interaction occurs in summon <-> provider exchanges, our ability to send to and conversely interpret anything special from the provider within the current architecture is very limited. If we try to coerce this architecture to support this use case, we will hit some issues like these:

• How is a variable with a newline in the value different from multiple variable value results?
• How will we let the provider know that we want multiple values (ID probably isn't enough)?
• How will we know what the name of the files for these values are since the current protocol only returns the value?
• What if the filename is not valid for the OS that we are running on?
• How do we deal with an error pulling out a single variable if all the other ones work?
• How will other providers deal with this if they don't support hierarchical credential storage?
• etc.

As you can see, it's a very complex implementation issue for seemingly an innocuous change. To properly solve this use case for you, the first step that would have to be done is re-architecting the communication protocol between summon and providers to be able to provide a rich binary interface and only then could we even consider the rest of the feasibility of this feature.

I will let someone else from the team comment on this too but I do not believe that we can realistically solve this with the current developer resources for the foreseeable future.

Srdjan

[boazmichaely]

Published in CyberArk Aha! idea portal

[cloudvant]

This is already doable with:

-D 'var=value' causes substitution of value to $var.

You can use the same secrets.yml file for different environments, using -D to substitute variables. This flag can be used multiple times.

Example

summon -D ENV=production --yaml 'SQL_PASSWORD: !var env/$ENV/db-password' deploy.sh

[OJFord]

That's not the same, your /db_password after the env var makes it still a single value, not the whole dir.