4

Example: I have an applications that needs to access an API providing an authentication token

myApi = MyApi(token=my_private_sensible_token)

I want to avoid having that private token in a configuration file that is part of the project.

One solution that comes to mind is to isolate interaction with this service in a separate proxy application that is maintained by a restricted number of authorised people. App-engine allows to protect handlers with authentication and I could easily, in the proxy, allow only calls coming from an authorised app-engine consumer application.

Different solutions I can think of, at certain point all make this private token available in the consumer application memory, this could allow a malicious user (that maintains the consumer) to write an handler that prints out this secret token that in some fancy way the application has retrieved.

Do you have better suggestions?

new name
  • 15,861
  • 19
  • 68
  • 114
JackNova
  • 3,911
  • 5
  • 31
  • 49
  • problem is, whatever you do if the code is able to get it, a malicious dev with access to the code will also be able to get it even from your proxy. – Zig Mandel Jul 10 '15 at 13:57
  • @ZigMandel with the proxy approach only the proxy knows the secret token to interact with the service, the consumer doesn't need to know it. The proxy should be maintained by a smaller set of authorised people – JackNova Jul 10 '15 at 16:30
  • the other devs can still abuse the proxy by pretending to be a valid user. but yea the proxy reduces the number of devs involved to hide the actual secret (but not from abuse of it) – Zig Mandel Jul 10 '15 at 16:31
  • @ZigMandel ok, clear – JackNova Jul 10 '15 at 16:39

1 Answers1

1

Another possible approach is to have 2 copies of the app (actually 2 different apps which happen to have the same code), each with their own app_ID, config file(s), etc:

  • one for development/staging, accessible by the larger development team
  • one for production - (possibly cloned/forked from the same SCM repo, maybe a private branch?) only accessible by the trusted devs and with the contents of the config file overwritten/updated for production deployment

Such setup can offer additional benefits besides just restricting access to production credentials, for example:

  • ability to use a CI system which includes automatic deployment on a very close to production environment
  • tighter control to production deployments
Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97