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?

4
  • 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. Commented Jul 10, 2015 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 Commented Jul 10, 2015 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) Commented Jul 10, 2015 at 16:31
  • @ZigMandel ok, clear Commented Jul 10, 2015 at 16:39

1 Answer 1

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
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.