Removal of TESLA_USERNAME and TESLA_PASSWORD from Environment Variables about teslamate HOT 9 CLOSED

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.

from teslamate.

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.

from teslamate.

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.

from teslamate.

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.

from teslamate.

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...)

from teslamate.

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

from teslamate.

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.

from teslamate.

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

from teslamate.

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?

from teslamate.