search

cyberark / cloudfoundry-conjur-buildpack

Buildpack for the Conjur / Cloud Foundry integration
Apache License 2.0
0 stars 3 forks source link

Error from 0001_retrieve-secrets #59

Closed cbarga closed 4 years ago

cbarga commented 4 years ago

One of our users is getting this error when pushing their app.

2020-03-13T13:51:13.26-0500 [APP/PROC/WEB/0] OUT [cyberark-conjur-buildpack]: retrieving & injecting secrets 2020-03-13T13:51:13.26-0500 [APP/PROC/WEB/0] OUT ~ ~ 2020-03-13T13:51:13.43-0500 [APP/PROC/WEB/0] ERR .profile.d/0001_retrieve-secrets.sh: line 44: export: `security.config.user.name=': not a valid identifier 2020-03-13T13:51:13.43-0500 [APP/PROC/WEB/0] ERR .profile.d/0001_retrieve-secrets.sh: Error on line 44 2020-03-13T13:51:13.45-0500 [APP/PROC/WEB/0] OUT Exit status 1 2020-03-13T13:51:13.45-0500 [CELL/SSHD/0] OUT Exit status 0

This is the matching line from their secrets.yml, where all of their entries follow the same format:

security.config.user.name: !var QA-CyberArkVault/PCF/DAP_PCF_RITM0283092/security_config_username/password

cbarga commented 4 years ago

The first ERR line had the actual value in the output and I tried to redact it in the copy/paste, but my redaction didn't show through.

cbarga commented 4 years ago

I had the user change their secrets.yml to use underscores instead of periods in the env var names, and that solved their problem.

izgeri commented 4 years ago

@cbarga thanks for reporting this! I'm sorry for the long delay before you received a response.

It looks like you are right, that we don't allow periods in the environment variable names. I know some systems support this, but it looks like our buildpack leverages the bash export method to set the variable names. The export method fails if the supplied name is not a valid shell variable name.

I've added an update to the README to hopefully make this clearer for other users in #65 - I'm glad you were able to figure this out, but I regret that you had to!

Since this issue appears to be resolved for you, I'll close this issue now.

TheSecMaven commented 4 years ago

this is a huge limiting factor. There is 3 issues with this method:

  1. the obvious cant use dots in variable names
  2. when you are viewing environment variables from PCF console you cant see these specified there, even for troubleshooting
  3. when you ssh into the container you still cant see them in the env variable, unlike every other variable being set with manifest.yml

how have people solved these cases? the buiildpack also doesn't fail on a push of an app when it CANT retrieve the credentials, so again left in the dark as to whether this worked or not at all. see https://github.com/cyberark/cloudfoundry-conjur-buildpack/issues/81

izgeri commented 4 years ago

@mkkeffeler the environment variables set by this buildpack are only loaded into the runtime process, which is consistent also with how the Summon project injects environment variables. We believe it is better for the security of these secret values that they are not exposed in the app manager UI or when you run cf env.

The variables that are being set are intended to have limited visibility; they are visible to the app that needs them, but not to any end users trying to access them.

If you want to validate the secrets.yml syntax or verify that the variables can be retrieved, you have some options. If you have a user that can access the variables, you can try to retrieve them by invoking summon and pointing it at the correct secrets.yml file:

summon -f /path/to/secrets.yml bash -c "printenv"

If you want to verify that a specific app deployed to TAS / connected to the Conjur service broker will have the correct access, you can log in via the CLI with a user with appropriate privileges and query:

conjur resource permitted_roles path/to/variable read
conjur resource permitted_roles path/to/variable execute

If the app is appropriately privileged, you should expect to see their host identity listed in the responses from the two requests above. The app identity is of the form {TAS policy branch}/{org guid}/{space guid}/{binding id} if using app-scoped identities and {TAS policy branch}/{org guid}/{space guid} if using space-scoped identities, where:

I hope this helps. It sounds like filing the issue #81 was the right call - we'll look into that shortly.