Expose more configuration options

[lucab]

This is a braindumping and tracking ticket for selecting and then exposing more configuration options via TOML. I'm still not settled on what's needed, so I'm collecting everything here. Feel free to chime in with more requests/suggestions.

• [ ] service
  • [ ] path_prefix (common API namespace)
  • [ ] misc TLS knobs (specific entries TBD)
• [ ] etcd3
  • [ ] username (client auth)
  • [ ] password_file (client auth)
  • [ ] dial_timeout_ms (transport timeout)
  • [ ] tls_cert_file (TLS auth)
  • [ ] tls_key_file (TLS auth)
• [ ] status (metrics exposition and more)
  • [ ] address (HTTP socket)
  • [ ] port (HTTP socket)

[eest]

Hello @lucab , thank you for working on this implementation of FleetLock. Having tested it I notice there currently is no support for authenticating to the backend etcd3 system which seems in line with the auth points on the wish list above. Is this something that is in scope of this project at this point?

I am also curious if there are any thoughts regarding authentication/authorization for the FleetLock speaking clients, that is, requiring some kind of authentication to be able to lock/unlock a given group.

The protocol description at https://coreos.github.io/zincati/development/fleetlock/protocol/ mentions nothing about authentication or authorization but I guess it is possible it is just considered out of scope and is up to the implementer?

[lucab]

Having tested it I notice there currently is no support for authenticating to the backend etcd3 system which seems in line with the auth points on the wish list above. Is this something that is in scope of this project at this point?

Absolutely yes, but I recently haven't had much time to spend on this codebase.

The protocol description at https://coreos.github.io/zincati/development/fleetlock/protocol/ mentions nothing about authentication or authorization but I guess it is possible it is just considered out of scope and is up to the implementer?

Yes, the protocol itself does not cover authentication. People usually have a very opinionated takes on authentication and key handling, so I think it is better to leave that out of the agent itself (i.e. Zincati). Also, in many cases the FleetLock server may only be reachable on a dedicated overlay network, via a proxy. One general approach thus would running a local proxy in a container (e.g. a daemonset pod), and pointing Zincati to it through localhost.