Publish and version dex's configuration format

[ericchiang]

A very common task when using dex is dynamically re-configuring it. Users install dex with static users then migrate to other connectors like LDAP. Doing this manually is often error prone but automating this process is hard without lots of YAML-foo.

Dex should take inspiration from Kubernetes' component config concept and start treating its configuration as a API that higher level config management systems (like Kubernetes) will have to interact with. This means formalizing, publishing, and versioning dex's configuration format. Possibly as a package, possibly as a JSON schema.

Useful links:

kubernetes/kubernetes#12245

Potential issues:

• Use of json.RawMessage is problematic since it's by definition unstructured. We might consider modifying our config format to take more explicit fields.

type Config struct {
    Connectors []Connector `json:"connectors"`
    // ...
}

type Connector struct {
    Name string `json:"name"`
    ID   string `json:"id"`

    // Enumerate connectors instead of using a RawMessage.
    LDAP *LDAPConnector `json:"ldap"`
    OIDC *OIDCConnector `json:"oidc"`
    SAML *SAMLConnector `json:"saml"`
}

• Having certain fields be magically evaluated as ENV vars is somewhat inconsistent since this acts on the raw bytes instead of holding additional fields.

Like json.RawMessage we might consider more explicit fields where filling in a field from an alternative source would be useful:

type Client struct {
    ClientSecret         string `json:"clientSecret"`
    ClientSecretFromEnv  string `json:"clientSecretFromEnv"`
    ClientSecretFromFile string `json:"clientSecretFromFile"`
}

cc @rithujohn191 @squat

[srenatus]

Heya -- Is there anything new to say about this? I'm just curious. Dynamic configuration of connectors would be sweet. 😍