Removal of TESLA_USERNAME and TESLA_PASSWORD from Environment Variables

[mvaal]

Can we brainstorm some ways we can remove TESLA_USERNAME and TESLA_PASSWORD from Environment Variables? These are visible from the container settings and I don't like my password sitting out in the open. Some sort of secrets manager or an endpoint that you can call that sets the credentials and starts the API after being called.

[mvaal]

Looks like docker has some built in secrets manager, but I think there will need to be code changes to actually read from the file system (as they are stored in files /run/secrets/). Let me know what you think, it could still support TESLA_USERNAME and TESLA_PASSWORD, but try to read from the secrets if not provided. I am willing to attempt the change but will probably take me a while to get to it.

[rfvgyhn]

As far as I know, secrets are only available when using a docker swarm.

Note: Docker secrets are only available to swarm services, not to standalone containers. To use this feature, consider adapting your container to run as a service. Stateful containers can typically run with a scale of 1 without changing the container code.

What I've done is use the env_file value for my username and password vars. I then make the env file's owner root and readable only by root. They are visible via docker inspect (e.g.available to any user that can run docker commands) but I figure since any user that has access to docker on the host also has root anyway, it's not a completely awful solution.

version: '3'
services:
  teslamate:
    env_file:
      - ./config/teslamate.env
  db:
    env_file:
      - ./config/postgres.env
  grafana:
    env_file:
      - ./config/grafana.env

sudo chown -R root:root config/ sudo chmod -R go-rwx config/

While I still don't like the idea of my password being in plaintext, that's the best I've come up with.

I think another option would be to add some logic into the entrypoint script that pulls in secrets from somewhere else (vault, credstash, keywhiz, etc...)

[mvaal]

Secret usage was added in docker-compose without swarm as of 1.11 (by using bind mounting) https://github.com/docker/compose/pull/4368 Yeah, vault was my first thought as well, but then I ran across this which seemed like less dependencies.

[rfvgyhn]

Very cool. I think that would be the way to go. Not having to pick just one external secret storage provider or support multiple would definitely be ideal.

[ChromoX]

What about expanding the web interface a bit to support adding accounts to TeslaMate? The username and password could then be stored in PostgreSQL or something like that.

[mvaal]

Oh, I like that idea a lot. Postgres should be able to store encrypted password I would think.

[adriankumpf]

Theoretically it wouldn't even be necessary to store the credentials. They are only required once to obtain the auth token from the Tesla API. The token would then go into the database.

I think adding a login view to the web interface is a great idea.

[scottismyname]

From what I understand, the auth token's do expire (90 days?). I haven't updated yet, but when they do expire, how will new auth tokens get generated?

[adriankumpf]

There are two kinds of tokens: access and refresh. At application startup and before the access token expires the refresh token is used to request a new pair of tokens.