Conjur API v4 (old Conjur Enterprise) requires secrets to be strings and allows you to specify a MIME type. API v5 (current Conjur.org and DAP) allows binary secrets and doesn’t require you to specify a MIME type.
creds: @ryan
edit: changed creds to link to Ryan’s account
@jake @ryan Can you please provide some example on how this can be done? I am not seeing much details in documentation.
I am trying add value to the secret variable using the following command. it stores only the content in not the file
conjur variable values add <policy/path/variable-id>
I am not seeing any reference on how to to store the text file in Conjur. Appreciate your help here! Thanks
@joe.garcia In the REST API collection and examples I did not find examples for storing a text file as secret in Conjur. I would appreciate if you could share some examples using may be curl or Powershell for storing text file as a secret.
Also when we read such secrets does it provide the content of the file back or the file itself.
Hey @sjohnkennedy, you can only store the contents of a file in a secret, not the whole file including permissions, filename, etc. The reason for this is that a secret only has a value, it doesn’t have any notion of a filesystem built in.
Here are two options off hand for you to capture the other parts of the file that you want to store in your secret:
tar zf <file> to create an archive of the secret file, and use that as your secret value. A tar includes the file metadata, so when you retrieve the secret and untar it, you’ll have the original file with the same name and permissions.@ryan Using Postman I was able to add a .tar file as a secret. However when I try to retrieve it I am not getting the tar file. Postman response is unreadable. I would appreciate if you could show examples on how to do this.
@ryan Would really appreciate your response as I am trying to solve a use case.
Hey again @sjohnkennedy I did make an attempt to provide an example today but got stuck, maybe somebody can spot something funky I’m doing.
Here’s a repo with the code & data I used, based on the Conjur quickstart. The readme has instructions showing what I did, how far I got and where it went off the rails.
Hope this helps! If not, I may take a crack at it again another day and see if I get further. I haven’t dived into the API calls yet etc to track down where the issue comes from. Not sure yet whether I’m doing something boneheaded or if I’m triggering a bug somewhere or what.
@ryan I am using DAP 11.4 and I am not sure if that changes anything. I already have a support ticket opened for this.
I am tagging @jody.hunt as he is aware of support ticket I am trying to get assistance.
To add the contents of the .bashrc file to a variable named mybashrc:
conjur variable values add mybashrc "$(cat ~/.bashrc)"
Value added
binary files should be gzipped and base64 encoded w/o line feeds before adding:
/# conjur variable values add mylscmd "$(gzip -c /bin/ls | base64 --wrap=0)"
reverse the process on retrieval:
/# conjur variable value mylscmd | base64 -d | gunzip -c > foo
/# chmod +x foo
/# foo
bin boot dev etc foo home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
For what it’s worth @jody.hunt that’s contradicted in the Conjur docs and tests, both of which state explicitly that a variable accepts binary data. Are the docs & tests both out of date or is there perhaps something we should look into more?
@jody.hunt @ryan Thank you for looking into this. We are literally converting the file into stream of characters when we are using gzip and encoding it and technically we are not storing files as such. I would really appreciate if we could get some confirmation on how this needs to be handled as early as possible!
@sjohnkennedy In general, we don’t recommend storing files as secrets, but if you must, they need to be as small as possible since they will be replicated to standbys and followers when they start up. White space and non-printable control characters complicate retrieval, so converting files to the smallest possible, all-printable-character representation (as this solution does) is really the only solution I can recommend.
We are aware in this example how we created the secret and are able to reverse the process when we retrieve the secret. if we need to do i this scalable fashion the secret itself should have some details how it can be put back in its original state so it can be consumed. Where can we put this metadata about the secret? If we need to use annotations for it, how could that be done for secrets syncing from CyberArk Vault.
To answer the part about secrets being synchronized from EPV to DAP for this use case, you can enable Server File Categories other than username and password to be synchronized from EPV to DAP. I would recommend creating a new “property” on the platform and add your own “annotations” for sync to DAP.
Or you could use an account naming convention like filename-gzb64. That way you’d know how to unpack the file and you could restore it to its original name.
Thanks Joe. I would have enable syncing all properties to from Cyberark to Conjur which would limit the number of the accounts that I can sync using a single LOB account. I will try both the options and see which one fits better.
Did you succeed by uploading a file to CyberArk PAS and sync all properties to Conjur and find a secret created on the Conjur ? and this can be retrieved as well as a secret by end applications ?
@gautamkanithi I did not work on that requirement after this conversation. Please update this thread if you are able to make any progress.