Please implement secret store support for backman with cloud foundary

[faizan-syed]

Hi @JamesClonk ,

While implementing the backman in cloud foundary I have noticed that there is no support for binding secret store in backman application. In my use case I am using the service binding for my database and passing the URI under $BACKMAN_CONFIG env variable but the DB password is visible in plain text under env variable when we run cf env backman which is not the best practice. We need some mechanism to hide the password. Need your help/advice here @JamesClonk

Even when we pass it using CLI as below these passwords are still visible in env variable

cf push -f manifest.yml --var username=backman --var password=my-password --var dbpassword=Super-secret-password

BACKMAN_CONFIG: |
      {
        "s3": {
          "service_label": "dynstrg",
          "bucket_name": "dev_s3"
        },
        "services": {
          "mariadb": {
            "schedule": "0 0 2,18,22 * * *",
            "retention": {
              "days": 90,
              "files": 20
            },
            "service_binding": {
              "type": "mysql",
              "provider": "mariadb",
              "host": "x.x.x.x", 
              "username": "root",
              "uri": "mysql://root:Super-secret-password@1x.x.x.x:5432/test",
              "password": "Super-secret-password",
              "database": "test",
              "port": 3306
            }
          }
        }
      }

[faizan-syed]

Hi ,

Do we have any thoughts on this? are we considering implementing this feature ?
@JamesClonk

[JamesClonk]

Hi @faizan-syed,

No, there are no plans to implement this.
Secret-store services are a non-standard thing (not CF in general, and certainly not Kubernetes. Backman also has to fit with Kubernetes paradigms), it would need custom logic for reading, parsing and templating these ontop of all other ENV vars and bindings (before even doing the normal service bindings parsing for CF/K8s) that would probably result in a very hacky codebase if it can even be reasonably implemented.

But more importantly it serves no purposes. There's no additional security to be gained. Environment variables are where you are supposed to store your credentials, users with enough permissions to read an app's ENV vars or user-provided services on CF can just as well push apps that print your entire secret-store values onto STDOUT or HTTP, etc.

If you are on CF I would suggest though to at least separate out your service credentials/bindings into user-provided service instances (see cf cups) instead of configuring these entirely in BACKMAN_CONFIG. This way they are stored within the VCAP_SERVICES ENV var and only users with SpaceDeveloper role can read those.
If you really do not want to have a particular secret appear in any ENV var whatsoever, then I would suggest to deploy Backman with a custom starter script that first fetches the needed secret-store values upon startup and populates them into the Backman config.json file instead of BACKMAN_CONFIG, and only after that starts the actual Backman binary.