2019-07-01 06:07:58 +08:00
|
|
|
// Copyright 2015 Matthew Holt and The Caddy Authors
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
2019-06-15 01:58:28 +08:00
|
|
|
package caddy
|
2019-03-27 05:45:51 +08:00
|
|
|
|
|
|
|
import (
|
2019-11-05 03:05:20 +08:00
|
|
|
"bytes"
|
2019-05-17 06:05:38 +08:00
|
|
|
"context"
|
2019-03-27 05:45:51 +08:00
|
|
|
"encoding/json"
|
|
|
|
"fmt"
|
2019-11-05 03:05:20 +08:00
|
|
|
"io"
|
2020-01-01 07:56:19 +08:00
|
|
|
"io/ioutil"
|
2019-03-27 09:42:52 +08:00
|
|
|
"log"
|
2019-11-05 03:05:20 +08:00
|
|
|
"net/http"
|
2020-01-01 13:51:55 +08:00
|
|
|
"os"
|
2019-11-05 03:05:20 +08:00
|
|
|
"path"
|
2020-01-01 13:51:55 +08:00
|
|
|
"path/filepath"
|
2019-06-29 09:28:28 +08:00
|
|
|
"runtime/debug"
|
2019-11-05 03:05:20 +08:00
|
|
|
"strconv"
|
2019-03-27 05:45:51 +08:00
|
|
|
"strings"
|
2019-03-27 09:42:52 +08:00
|
|
|
"sync"
|
2019-03-27 05:45:51 +08:00
|
|
|
"time"
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2020-03-07 14:15:25 +08:00
|
|
|
"github.com/caddyserver/certmagic"
|
2020-01-01 07:56:19 +08:00
|
|
|
"go.uber.org/zap"
|
2019-03-27 05:45:51 +08:00
|
|
|
)
|
|
|
|
|
2019-12-11 04:36:46 +08:00
|
|
|
// Config is the top (or beginning) of the Caddy configuration structure.
|
|
|
|
// Caddy config is expressed natively as a JSON document. If you prefer
|
|
|
|
// not to work with JSON directly, there are [many config adapters](/docs/config-adapters)
|
|
|
|
// available that can convert various inputs into Caddy JSON.
|
|
|
|
//
|
|
|
|
// Many parts of this config are extensible through the use of Caddy modules.
|
|
|
|
// Fields which have a json.RawMessage type and which appear as dots (•••) in
|
|
|
|
// the online docs can be fulfilled by modules in a certain module
|
|
|
|
// namespace. The docs show which modules can be used in a given place.
|
|
|
|
//
|
|
|
|
// Whenever a module is used, its name must be given either inline as part of
|
|
|
|
// the module, or as the key to the module's value. The docs will make it clear
|
|
|
|
// which to use.
|
|
|
|
//
|
|
|
|
// Generally, all config settings are optional, as it is Caddy convention to
|
|
|
|
// have good, documented default values. If a parameter is required, the docs
|
|
|
|
// should say so.
|
|
|
|
//
|
|
|
|
// Go programs which are directly building a Config struct value should take
|
|
|
|
// care to populate the JSON-encodable fields of the struct (i.e. the fields
|
|
|
|
// with `json` struct tags) if employing the module lifecycle (e.g. Provision
|
|
|
|
// method calls).
|
2019-06-29 09:28:28 +08:00
|
|
|
type Config struct {
|
2019-12-11 04:36:46 +08:00
|
|
|
Admin *AdminConfig `json:"admin,omitempty"`
|
|
|
|
Logging *Logging `json:"logging,omitempty"`
|
|
|
|
|
|
|
|
// StorageRaw is a storage module that defines how/where Caddy
|
2020-01-01 09:31:43 +08:00
|
|
|
// stores assets (such as TLS certificates). The default storage
|
|
|
|
// module is `caddy.storage.file_system` (the local file system),
|
|
|
|
// and the default path
|
|
|
|
// [depends on the OS and environment](/docs/conventions#data-directory).
|
2019-12-11 04:36:46 +08:00
|
|
|
StorageRaw json.RawMessage `json:"storage,omitempty" caddy:"namespace=caddy.storage inline_key=module"`
|
|
|
|
|
|
|
|
// AppsRaw are the apps that Caddy will load and run. The
|
|
|
|
// app module name is the key, and the app's config is the
|
|
|
|
// associated value.
|
|
|
|
AppsRaw ModuleMap `json:"apps,omitempty" caddy:"namespace="`
|
2019-06-29 09:28:28 +08:00
|
|
|
|
2019-10-29 04:39:37 +08:00
|
|
|
apps map[string]App
|
|
|
|
storage certmagic.Storage
|
2019-06-29 09:28:28 +08:00
|
|
|
|
|
|
|
cancelFunc context.CancelFunc
|
|
|
|
}
|
|
|
|
|
|
|
|
// App is a thing that Caddy runs.
|
|
|
|
type App interface {
|
|
|
|
Start() error
|
|
|
|
Stop() error
|
|
|
|
}
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
// Run runs the given config, replacing any existing config.
|
|
|
|
func Run(cfg *Config) error {
|
|
|
|
cfgJSON, err := json.Marshal(cfg)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
return Load(cfgJSON, true)
|
|
|
|
}
|
|
|
|
|
|
|
|
// Load loads the given config JSON and runs it only
|
|
|
|
// if it is different from the current config or
|
|
|
|
// forceReload is true.
|
|
|
|
func Load(cfgJSON []byte, forceReload bool) error {
|
|
|
|
return changeConfig(http.MethodPost, "/"+rawConfigKey, cfgJSON, forceReload)
|
|
|
|
}
|
|
|
|
|
|
|
|
// changeConfig changes the current config (rawCfg) according to the
|
|
|
|
// method, traversed via the given path, and uses the given input as
|
|
|
|
// the new value (if applicable; i.e. "DELETE" doesn't have an input).
|
|
|
|
// If the resulting config is the same as the previous, no reload will
|
|
|
|
// occur unless forceReload is true. This function is safe for
|
|
|
|
// concurrent use.
|
|
|
|
func changeConfig(method, path string, input []byte, forceReload bool) error {
|
|
|
|
switch method {
|
|
|
|
case http.MethodGet,
|
|
|
|
http.MethodHead,
|
|
|
|
http.MethodOptions,
|
|
|
|
http.MethodConnect,
|
|
|
|
http.MethodTrace:
|
|
|
|
return fmt.Errorf("method not allowed")
|
|
|
|
}
|
|
|
|
|
2019-05-17 06:05:38 +08:00
|
|
|
currentCfgMu.Lock()
|
|
|
|
defer currentCfgMu.Unlock()
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
err := unsyncedConfigAccess(method, path, input, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
// the mutation is complete, so encode the entire config as JSON
|
|
|
|
newCfg, err := json.Marshal(rawCfg[rawConfigKey])
|
|
|
|
if err != nil {
|
|
|
|
return APIError{
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
HTTPStatus: http.StatusBadRequest,
|
|
|
|
Err: fmt.Errorf("encoding new config: %v", err),
|
2019-11-05 03:05:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// if nothing changed, no need to do a whole reload unless the client forces it
|
|
|
|
if !forceReload && bytes.Equal(rawCfgJSON, newCfg) {
|
2019-12-16 03:58:01 +08:00
|
|
|
Log().Named("admin.api").Info("config is unchanged")
|
2019-11-05 03:05:20 +08:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2019-11-28 02:49:49 +08:00
|
|
|
// find any IDs in this config and index them
|
|
|
|
idx := make(map[string]string)
|
|
|
|
err = indexConfigObjects(rawCfg[rawConfigKey], "/"+rawConfigKey, idx)
|
|
|
|
if err != nil {
|
|
|
|
return APIError{
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
HTTPStatus: http.StatusInternalServerError,
|
|
|
|
Err: fmt.Errorf("indexing config: %v", err),
|
2019-11-28 02:49:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
// load this new config; if it fails, we need to revert to
|
|
|
|
// our old representation of caddy's actual config
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
err = unsyncedDecodeAndRun(newCfg, true)
|
2019-11-05 03:05:20 +08:00
|
|
|
if err != nil {
|
|
|
|
if len(rawCfgJSON) > 0 {
|
|
|
|
// restore old config state to keep it consistent
|
|
|
|
// with what caddy is still running; we need to
|
|
|
|
// unmarshal it again because it's likely that
|
|
|
|
// pointers deep in our rawCfg map were modified
|
|
|
|
var oldCfg interface{}
|
|
|
|
err2 := json.Unmarshal(rawCfgJSON, &oldCfg)
|
|
|
|
if err2 != nil {
|
|
|
|
err = fmt.Errorf("%v; additionally, restoring old config: %v", err, err2)
|
|
|
|
}
|
|
|
|
rawCfg[rawConfigKey] = oldCfg
|
|
|
|
}
|
|
|
|
|
|
|
|
return fmt.Errorf("loading new config: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// success, so update our stored copy of the encoded
|
|
|
|
// config to keep it consistent with what caddy is now
|
|
|
|
// running (storing an encoded copy is not strictly
|
|
|
|
// necessary, but avoids an extra json.Marshal for
|
|
|
|
// each config change)
|
|
|
|
rawCfgJSON = newCfg
|
|
|
|
rawCfgIndex = idx
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// readConfig traverses the current config to path
|
|
|
|
// and writes its JSON encoding to out.
|
|
|
|
func readConfig(path string, out io.Writer) error {
|
|
|
|
currentCfgMu.RLock()
|
|
|
|
defer currentCfgMu.RUnlock()
|
|
|
|
return unsyncedConfigAccess(http.MethodGet, path, nil, out)
|
|
|
|
}
|
|
|
|
|
2020-02-27 13:22:40 +08:00
|
|
|
// indexConfigObjects recursively searches ptr for object fields named
|
2019-11-05 03:05:20 +08:00
|
|
|
// "@id" and maps that ID value to the full configPath in the index.
|
|
|
|
// This function is NOT safe for concurrent access; obtain a write lock
|
|
|
|
// on currentCfgMu.
|
|
|
|
func indexConfigObjects(ptr interface{}, configPath string, index map[string]string) error {
|
|
|
|
switch val := ptr.(type) {
|
|
|
|
case map[string]interface{}:
|
|
|
|
for k, v := range val {
|
|
|
|
if k == idKey {
|
|
|
|
switch idVal := v.(type) {
|
|
|
|
case string:
|
|
|
|
index[idVal] = configPath
|
|
|
|
case float64: // all JSON numbers decode as float64
|
|
|
|
index[fmt.Sprintf("%v", idVal)] = configPath
|
|
|
|
default:
|
|
|
|
return fmt.Errorf("%s: %s field must be a string or number", configPath, idKey)
|
|
|
|
}
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
// traverse this object property recursively
|
|
|
|
err := indexConfigObjects(val[k], path.Join(configPath, k), index)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
case []interface{}:
|
|
|
|
// traverse each element of the array recursively
|
|
|
|
for i := range val {
|
|
|
|
err := indexConfigObjects(val[i], path.Join(configPath, strconv.Itoa(i)), index)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-01-01 07:56:19 +08:00
|
|
|
// unsyncedDecodeAndRun removes any meta fields (like @id tags)
|
|
|
|
// from cfgJSON, decodes the result into a *Config, and runs
|
|
|
|
// it as the new config, replacing any other current config.
|
|
|
|
// It does NOT update the raw config state, as this is a
|
|
|
|
// lower-level function; most callers will want to use Load
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
// instead. A write lock on currentCfgMu is required! If
|
|
|
|
// allowPersist is false, it will not be persisted to disk,
|
|
|
|
// even if it is configured to.
|
|
|
|
func unsyncedDecodeAndRun(cfgJSON []byte, allowPersist bool) error {
|
2020-01-01 07:56:19 +08:00
|
|
|
// remove any @id fields from the JSON, which would cause
|
|
|
|
// loading to break since the field wouldn't be recognized
|
|
|
|
strippedCfgJSON := RemoveMetaFields(cfgJSON)
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
var newCfg *Config
|
2020-01-01 07:56:19 +08:00
|
|
|
err := strictUnmarshalJSON(strippedCfgJSON, &newCfg)
|
2019-11-05 03:05:20 +08:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
// prevent recursive config loads; that is a user error, and
|
|
|
|
// although frequent config loads should be safe, we cannot
|
|
|
|
// guarantee that in the presence of third party plugins, nor
|
|
|
|
// do we want this error to go unnoticed (we assume it was a
|
|
|
|
// pulled config if we're not allowed to persist it)
|
|
|
|
if !allowPersist &&
|
|
|
|
newCfg != nil &&
|
|
|
|
newCfg.Admin != nil &&
|
|
|
|
newCfg.Admin.Config != nil &&
|
|
|
|
newCfg.Admin.Config.LoadRaw != nil {
|
|
|
|
return fmt.Errorf("recursive config loading detected: pulled configs cannot pull other configs")
|
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// run the new config and start all its apps
|
2019-11-05 03:05:20 +08:00
|
|
|
err = run(newCfg, true)
|
2019-09-30 23:16:01 +08:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
// swap old config with the new one
|
|
|
|
oldCfg := currentCfg
|
|
|
|
currentCfg = newCfg
|
2019-05-17 06:05:38 +08:00
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// Stop, Cleanup each old app
|
|
|
|
unsyncedStop(oldCfg)
|
|
|
|
|
2020-01-01 07:56:19 +08:00
|
|
|
// autosave a non-nil config, if not disabled
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
if allowPersist &&
|
|
|
|
newCfg != nil &&
|
2020-01-01 07:56:19 +08:00
|
|
|
(newCfg.Admin == nil ||
|
|
|
|
newCfg.Admin.Config == nil ||
|
|
|
|
newCfg.Admin.Config.Persist == nil ||
|
|
|
|
*newCfg.Admin.Config.Persist) {
|
2020-01-01 13:51:55 +08:00
|
|
|
dir := filepath.Dir(ConfigAutosavePath)
|
|
|
|
err := os.MkdirAll(dir, 0700)
|
|
|
|
if err != nil {
|
|
|
|
Log().Error("unable to create folder for config autosave",
|
|
|
|
zap.String("dir", dir),
|
2020-01-01 07:56:19 +08:00
|
|
|
zap.Error(err))
|
2020-01-01 13:51:55 +08:00
|
|
|
} else {
|
|
|
|
err := ioutil.WriteFile(ConfigAutosavePath, cfgJSON, 0600)
|
|
|
|
if err == nil {
|
2021-02-25 02:55:56 +08:00
|
|
|
Log().Info("autosaved config (load with --resume flag)", zap.String("file", ConfigAutosavePath))
|
2020-01-01 13:51:55 +08:00
|
|
|
} else {
|
|
|
|
Log().Error("unable to autosave config",
|
|
|
|
zap.String("file", ConfigAutosavePath),
|
|
|
|
zap.Error(err))
|
|
|
|
}
|
2020-01-01 07:56:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// run runs newCfg and starts all its apps if
|
|
|
|
// start is true. If any errors happen, cleanup
|
|
|
|
// is performed if any modules were provisioned;
|
|
|
|
// apps that were started already will be stopped,
|
|
|
|
// so this function should not leak resources if
|
2019-10-29 04:39:37 +08:00
|
|
|
// an error is returned. However, if no error is
|
|
|
|
// returned and start == false, you should cancel
|
|
|
|
// the config if you are not going to start it,
|
|
|
|
// so that each provisioned module will be
|
|
|
|
// cleaned up.
|
2019-11-05 03:05:20 +08:00
|
|
|
//
|
|
|
|
// This is a low-level function; most callers
|
|
|
|
// will want to use Run instead, which also
|
|
|
|
// updates the config's raw state.
|
2019-09-30 23:16:01 +08:00
|
|
|
func run(newCfg *Config, start bool) error {
|
|
|
|
// because we will need to roll back any state
|
|
|
|
// modifications if this function errors, we
|
|
|
|
// keep a single error value and scope all
|
|
|
|
// sub-operations to their own functions to
|
|
|
|
// ensure this error value does not get
|
|
|
|
// overridden or missed when it should have
|
|
|
|
// been set by a short assignment
|
|
|
|
var err error
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
if newCfg == nil {
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
newCfg = new(Config)
|
2019-11-05 03:05:20 +08:00
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// create a context within which to load
|
|
|
|
// modules - essentially our new config's
|
|
|
|
// execution environment; be sure that
|
|
|
|
// cleanup occurs when we return if there
|
|
|
|
// was an error; if no error, it will get
|
|
|
|
// cleaned up on next config cycle
|
|
|
|
ctx, cancel := NewContext(Context{Context: context.Background(), cfg: newCfg})
|
|
|
|
defer func() {
|
2019-05-17 06:05:38 +08:00
|
|
|
if err != nil {
|
2019-10-29 04:39:37 +08:00
|
|
|
// if there were any errors during startup,
|
|
|
|
// we should cancel the new context we created
|
|
|
|
// since the associated config won't be used;
|
|
|
|
// this will cause all modules that were newly
|
|
|
|
// provisioned to clean themselves up
|
|
|
|
cancel()
|
|
|
|
|
|
|
|
// also undo any other state changes we made
|
|
|
|
if currentCfg != nil {
|
|
|
|
certmagic.Default.Storage = currentCfg.storage
|
|
|
|
}
|
2019-03-27 09:42:52 +08:00
|
|
|
}
|
2019-09-30 23:16:01 +08:00
|
|
|
}()
|
|
|
|
newCfg.cancelFunc = cancel // clean up later
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2019-10-29 04:39:37 +08:00
|
|
|
// set up logging before anything bad happens
|
2019-10-30 01:58:29 +08:00
|
|
|
if newCfg.Logging == nil {
|
|
|
|
newCfg.Logging = new(Logging)
|
|
|
|
}
|
|
|
|
err = newCfg.Logging.openLogs(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
2019-10-29 04:39:37 +08:00
|
|
|
}
|
|
|
|
|
2021-02-24 03:57:10 +08:00
|
|
|
// start the admin endpoint (and stop any prior one)
|
|
|
|
if start {
|
|
|
|
err = replaceLocalAdminServer(newCfg)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("starting caddy administration endpoint: %v", err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// prepare the new config for use
|
|
|
|
newCfg.apps = make(map[string]App)
|
|
|
|
|
2019-10-29 04:39:37 +08:00
|
|
|
// set up global storage and make it CertMagic's default storage, too
|
2019-09-30 23:16:01 +08:00
|
|
|
err = func() error {
|
|
|
|
if newCfg.StorageRaw != nil {
|
2019-12-11 04:36:46 +08:00
|
|
|
val, err := ctx.LoadModule(newCfg, "StorageRaw")
|
2019-09-30 23:16:01 +08:00
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("loading storage module: %v", err)
|
2019-05-17 06:05:38 +08:00
|
|
|
}
|
2019-09-30 23:16:01 +08:00
|
|
|
stor, err := val.(StorageConverter).CertMagicStorage()
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("creating storage value: %v", err)
|
|
|
|
}
|
|
|
|
newCfg.storage = stor
|
2019-04-08 14:00:14 +08:00
|
|
|
}
|
2019-12-11 04:36:46 +08:00
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
if newCfg.storage == nil {
|
2020-04-01 07:56:36 +08:00
|
|
|
newCfg.storage = DefaultStorage
|
2019-09-30 23:16:01 +08:00
|
|
|
}
|
|
|
|
certmagic.Default.Storage = newCfg.storage
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
return nil
|
|
|
|
}()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2020-03-07 14:15:25 +08:00
|
|
|
// Load and Provision each app and their submodules
|
2019-09-30 23:16:01 +08:00
|
|
|
err = func() error {
|
2020-03-07 14:15:25 +08:00
|
|
|
for appName := range newCfg.AppsRaw {
|
|
|
|
if _, err := ctx.App(appName); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2019-04-08 14:00:14 +08:00
|
|
|
}
|
2019-09-30 23:16:01 +08:00
|
|
|
return nil
|
|
|
|
}()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
2019-04-26 03:54:48 +08:00
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
if !start {
|
|
|
|
return nil
|
|
|
|
}
|
2019-04-26 03:54:48 +08:00
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// Start
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
err = func() error {
|
2019-09-30 23:16:01 +08:00
|
|
|
var started []string
|
|
|
|
for name, a := range newCfg.apps {
|
|
|
|
err := a.Start()
|
|
|
|
if err != nil {
|
|
|
|
// an app failed to start, so we need to stop
|
|
|
|
// all other apps that were already started
|
|
|
|
for _, otherAppName := range started {
|
|
|
|
err2 := newCfg.apps[otherAppName].Stop()
|
|
|
|
if err2 != nil {
|
|
|
|
err = fmt.Errorf("%v; additionally, aborting app %s: %v",
|
|
|
|
err, otherAppName, err2)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return fmt.Errorf("%s app module: start: %v", name, err)
|
|
|
|
}
|
|
|
|
started = append(started, name)
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}()
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
// now that the user's config is running, finish setting up anything else,
|
|
|
|
// such as remote admin endpoint, config loader, etc.
|
|
|
|
return finishSettingUp(ctx, newCfg)
|
|
|
|
}
|
|
|
|
|
|
|
|
// finishSettingUp should be run after all apps have successfully started.
|
|
|
|
func finishSettingUp(ctx Context, cfg *Config) error {
|
|
|
|
// establish this server's identity (only after apps are loaded
|
|
|
|
// so that cert management of this endpoint doesn't prevent user's
|
|
|
|
// servers from starting which likely also use HTTP/HTTPS ports;
|
|
|
|
// but before remote management which may depend on these creds)
|
|
|
|
err := manageIdentity(ctx, cfg)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("provisioning remote admin endpoint: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// replace any remote admin endpoint
|
|
|
|
err = replaceRemoteAdminServer(ctx, cfg)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("provisioning remote admin endpoint: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// if dynamic config is requested, set that up and run it
|
|
|
|
if cfg != nil && cfg.Admin != nil && cfg.Admin.Config != nil && cfg.Admin.Config.LoadRaw != nil {
|
|
|
|
val, err := ctx.LoadModule(cfg.Admin.Config, "LoadRaw")
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("loading config loader module: %s", err)
|
|
|
|
}
|
|
|
|
loadedConfig, err := val.(ConfigLoader).LoadConfig(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("loading dynamic config from %T: %v", val, err)
|
|
|
|
}
|
|
|
|
|
|
|
|
// do this in a goroutine so current config can finish being loaded; otherwise deadlock
|
|
|
|
go func() {
|
|
|
|
Log().Info("applying dynamically-loaded config", zap.String("loader_module", val.(Module).CaddyModule().ID.Name()))
|
|
|
|
currentCfgMu.Lock()
|
|
|
|
err := unsyncedDecodeAndRun(loadedConfig, false)
|
|
|
|
currentCfgMu.Unlock()
|
|
|
|
if err == nil {
|
|
|
|
Log().Info("dynamically-loaded config applied successfully")
|
|
|
|
} else {
|
|
|
|
Log().Error("running dynamically-loaded config failed", zap.Error(err))
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// ConfigLoader is a type that can load a Caddy config. The
|
|
|
|
// returned config must be valid Caddy JSON.
|
|
|
|
type ConfigLoader interface {
|
|
|
|
LoadConfig(Context) ([]byte, error)
|
2019-07-13 00:07:11 +08:00
|
|
|
}
|
2019-04-03 05:31:02 +08:00
|
|
|
|
2019-07-13 00:07:11 +08:00
|
|
|
// Stop stops running the current configuration.
|
|
|
|
// It is the antithesis of Run(). This function
|
|
|
|
// will log any errors that occur during the
|
|
|
|
// stopping of individual apps and continue to
|
2019-11-05 03:05:20 +08:00
|
|
|
// stop the others. Stop should only be called
|
|
|
|
// if not replacing with a new config.
|
2019-07-13 00:07:11 +08:00
|
|
|
func Stop() error {
|
|
|
|
currentCfgMu.Lock()
|
|
|
|
defer currentCfgMu.Unlock()
|
|
|
|
unsyncedStop(currentCfg)
|
|
|
|
currentCfg = nil
|
2019-11-05 03:05:20 +08:00
|
|
|
rawCfgJSON = nil
|
|
|
|
rawCfgIndex = nil
|
|
|
|
rawCfg[rawConfigKey] = nil
|
2019-03-27 05:45:51 +08:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
// unsyncedStop stops cfg from running, but has
|
|
|
|
// no locking around cfg. It is a no-op if cfg is
|
|
|
|
// nil. If any app returns an error when stopping,
|
|
|
|
// it is logged and the function continues stopping
|
|
|
|
// the next app. This function assumes all apps in
|
|
|
|
// cfg were successfully started first.
|
2019-09-30 23:16:01 +08:00
|
|
|
func unsyncedStop(cfg *Config) {
|
|
|
|
if cfg == nil {
|
2019-07-13 00:07:11 +08:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
// stop each app
|
2019-09-30 23:16:01 +08:00
|
|
|
for name, a := range cfg.apps {
|
2019-07-13 00:07:11 +08:00
|
|
|
err := a.Stop()
|
|
|
|
if err != nil {
|
|
|
|
log.Printf("[ERROR] stop %s: %v", name, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-30 23:16:01 +08:00
|
|
|
// clean up all modules
|
|
|
|
cfg.cancelFunc()
|
|
|
|
}
|
|
|
|
|
|
|
|
// Validate loads, provisions, and validates
|
|
|
|
// cfg, but does not start running it.
|
|
|
|
func Validate(cfg *Config) error {
|
2019-10-29 04:39:37 +08:00
|
|
|
err := run(cfg, false)
|
|
|
|
if err == nil {
|
|
|
|
cfg.cancelFunc() // call Cleanup on all modules
|
|
|
|
}
|
|
|
|
return err
|
2019-07-13 00:07:11 +08:00
|
|
|
}
|
|
|
|
|
admin: Identity management, remote admin, config loaders (#3994)
This commits dds 3 separate, but very related features:
1. Automated server identity management
How do you know you're connecting to the server you think you are? How do you know the server connecting to you is the server instance you think it is? Mutually-authenticated TLS (mTLS) answers both of these questions. Using TLS to authenticate requires a public/private key pair (and the peer must trust the certificate you present to it).
Fortunately, Caddy is really good at managing certificates by now. We tap into that power to make it possible for Caddy to obtain and renew its own identity credentials, or in other words, a certificate that can be used for both server verification when clients connect to it, and client verification when it connects to other servers. Its associated private key is essentially its identity, and TLS takes care of possession proofs.
This configuration is simply a list of identifiers and an optional list of custom certificate issuers. Identifiers are things like IP addresses or DNS names that can be used to access the Caddy instance. The default issuers are ZeroSSL and Let's Encrypt, but these are public CAs, so they won't issue certs for private identifiers. Caddy will simply manage credentials for these, which other parts of Caddy can use, for example: remote administration or dynamic config loading (described below).
2. Remote administration over secure connection
This feature adds generic remote admin functionality that is safe to expose on a public interface.
- The "remote" (or "secure") endpoint is optional. It does not affect the standard/local/plaintext endpoint.
- It's the same as the [API endpoint on localhost:2019](https://caddyserver.com/docs/api), but over TLS.
- TLS cannot be disabled on this endpoint.
- TLS mutual auth is required, and cannot be disabled.
- The server's certificate _must_ be obtained and renewed via automated means, such as ACME. It cannot be manually loaded.
- The TLS server takes care of verifying the client.
- The admin handler takes care of application-layer permissions (methods and paths that each client is allowed to use).\
- Sensible defaults are still WIP.
- Config fields subject to change/renaming.
3. Dyanmic config loading at startup
Since this feature was planned in tandem with remote admin, and depends on its changes, I am combining them into one PR.
Dynamic config loading is where you tell Caddy how to load its config, and then it loads and runs that. First, it will load the config you give it (and persist that so it can be optionally resumed later). Then, it will try pulling its _actual_ config using the module you've specified (dynamically loaded configs are _not_ persisted to storage, since resuming them doesn't make sense).
This PR comes with a standard config loader module called `caddy.config_loaders.http`.
Caddyfile config for all of this can probably be added later.
COMMITS:
* admin: Secure socket for remote management
Functional, but still WIP.
Optional secure socket for the admin endpoint is designed
for remote management, i.e. to be exposed on a public
port. It enforces TLS mutual authentication which cannot
be disabled. The default port for this is :2021. The server
certificate cannot be specified manually, it MUST be
obtained from a certificate issuer (i.e. ACME).
More polish and sensible defaults are still in development.
Also cleaned up and consolidated the code related to
quitting the process.
* Happy lint
* Implement dynamic config loading; HTTP config loader module
This allows Caddy to load a dynamic config when it starts.
Dynamically-loaded configs are intentionally not persisted to storage.
Includes an implementation of the standard config loader, HTTPLoader.
Can be used to download configs over HTTP(S).
* Refactor and cleanup; prevent recursive config pulls
Identity management is now separated from remote administration.
There is no need to enable remote administration if all you want is identity
management, but you will need to configure identity management
if you want remote administration.
* Fix lint warnings
* Rename identities->identifiers for consistency
2021-01-28 07:16:04 +08:00
|
|
|
// exitProcess exits the process as gracefully as possible,
|
|
|
|
// but it always exits, even if there are errors doing so.
|
|
|
|
// It stops all apps, cleans up external locks, removes any
|
|
|
|
// PID file, and shuts down admin endpoint(s) in a goroutine.
|
|
|
|
// Errors are logged along the way, and an appropriate exit
|
|
|
|
// code is emitted.
|
|
|
|
func exitProcess(logger *zap.Logger) {
|
|
|
|
if logger == nil {
|
|
|
|
logger = Log()
|
|
|
|
}
|
|
|
|
logger.Warn("exiting; byeee!! 👋")
|
|
|
|
|
|
|
|
exitCode := ExitCodeSuccess
|
|
|
|
|
|
|
|
// stop all apps
|
|
|
|
if err := Stop(); err != nil {
|
|
|
|
logger.Error("failed to stop apps", zap.Error(err))
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
}
|
|
|
|
|
|
|
|
// clean up certmagic locks
|
|
|
|
certmagic.CleanUpOwnLocks(logger)
|
|
|
|
|
|
|
|
// remove pidfile
|
|
|
|
if pidfile != "" {
|
|
|
|
err := os.Remove(pidfile)
|
|
|
|
if err != nil {
|
|
|
|
logger.Error("cleaning up PID file:",
|
|
|
|
zap.String("pidfile", pidfile),
|
|
|
|
zap.Error(err))
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// shut down admin endpoint(s) in goroutines so that
|
|
|
|
// if this function was called from an admin handler,
|
|
|
|
// it has a chance to return gracefully
|
|
|
|
// use goroutine so that we can finish responding to API request
|
|
|
|
go func() {
|
|
|
|
defer func() {
|
|
|
|
logger = logger.With(zap.Int("exit_code", exitCode))
|
|
|
|
if exitCode == ExitCodeSuccess {
|
|
|
|
logger.Info("shutdown complete")
|
|
|
|
} else {
|
|
|
|
logger.Error("unclean shutdown")
|
|
|
|
}
|
|
|
|
os.Exit(exitCode)
|
|
|
|
}()
|
|
|
|
|
|
|
|
if remoteAdminServer != nil {
|
|
|
|
err := stopAdminServer(remoteAdminServer)
|
|
|
|
if err != nil {
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
logger.Error("failed to stop remote admin server gracefully", zap.Error(err))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if localAdminServer != nil {
|
|
|
|
err := stopAdminServer(localAdminServer)
|
|
|
|
if err != nil {
|
|
|
|
exitCode = ExitCodeFailedQuit
|
|
|
|
logger.Error("failed to stop local admin server gracefully", zap.Error(err))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
2019-12-11 04:36:46 +08:00
|
|
|
// Duration can be an integer or a string. An integer is
|
|
|
|
// interpreted as nanoseconds. If a string, it is a Go
|
|
|
|
// time.Duration value such as `300ms`, `1.5h`, or `2h45m`;
|
2020-05-12 06:41:11 +08:00
|
|
|
// valid units are `ns`, `us`/`µs`, `ms`, `s`, `m`, `h`, and `d`.
|
2019-03-27 05:45:51 +08:00
|
|
|
type Duration time.Duration
|
|
|
|
|
|
|
|
// UnmarshalJSON satisfies json.Unmarshaler.
|
2019-04-01 10:41:29 +08:00
|
|
|
func (d *Duration) UnmarshalJSON(b []byte) error {
|
2019-11-05 03:54:46 +08:00
|
|
|
if len(b) == 0 {
|
|
|
|
return io.EOF
|
2019-04-01 10:41:29 +08:00
|
|
|
}
|
2019-11-05 03:54:46 +08:00
|
|
|
var dur time.Duration
|
|
|
|
var err error
|
|
|
|
if b[0] == byte('"') && b[len(b)-1] == byte('"') {
|
2020-05-12 06:41:11 +08:00
|
|
|
dur, err = ParseDuration(strings.Trim(string(b), `"`))
|
2019-11-05 03:54:46 +08:00
|
|
|
} else {
|
|
|
|
err = json.Unmarshal(b, &dur)
|
|
|
|
}
|
|
|
|
*d = Duration(dur)
|
|
|
|
return err
|
2019-03-27 05:45:51 +08:00
|
|
|
}
|
|
|
|
|
2020-05-12 06:41:11 +08:00
|
|
|
// ParseDuration parses a duration string, adding
|
|
|
|
// support for the "d" unit meaning number of days,
|
|
|
|
// where a day is assumed to be 24h.
|
|
|
|
func ParseDuration(s string) (time.Duration, error) {
|
|
|
|
var inNumber bool
|
|
|
|
var numStart int
|
|
|
|
for i := 0; i < len(s); i++ {
|
|
|
|
ch := s[i]
|
|
|
|
if ch == 'd' {
|
|
|
|
daysStr := s[numStart:i]
|
|
|
|
days, err := strconv.ParseFloat(daysStr, 64)
|
|
|
|
if err != nil {
|
|
|
|
return 0, err
|
|
|
|
}
|
|
|
|
hours := days * 24.0
|
|
|
|
hoursStr := strconv.FormatFloat(hours, 'f', -1, 64)
|
|
|
|
s = s[:numStart] + hoursStr + "h" + s[i+1:]
|
|
|
|
i--
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if !inNumber {
|
|
|
|
numStart = i
|
|
|
|
}
|
|
|
|
inNumber = (ch >= '0' && ch <= '9') || ch == '.' || ch == '-' || ch == '+'
|
|
|
|
}
|
|
|
|
return time.ParseDuration(s)
|
|
|
|
}
|
|
|
|
|
2019-06-29 09:28:28 +08:00
|
|
|
// GoModule returns the build info of this Caddy
|
|
|
|
// build from debug.BuildInfo (requires Go modules).
|
|
|
|
// If no version information is available, a non-nil
|
|
|
|
// value will still be returned, but with an
|
|
|
|
// unknown version.
|
2019-08-08 13:59:02 +08:00
|
|
|
func GoModule() *debug.Module {
|
|
|
|
var mod debug.Module
|
|
|
|
return goModule(&mod)
|
|
|
|
}
|
|
|
|
|
|
|
|
// goModule holds the actual implementation of GoModule.
|
|
|
|
// Allocating debug.Module in GoModule() and passing a
|
|
|
|
// reference to goModule enables mid-stack inlining.
|
|
|
|
func goModule(mod *debug.Module) *debug.Module {
|
|
|
|
mod.Version = "unknown"
|
2019-06-29 09:28:28 +08:00
|
|
|
bi, ok := debug.ReadBuildInfo()
|
|
|
|
if ok {
|
2019-07-13 00:15:27 +08:00
|
|
|
mod.Path = bi.Main.Path
|
2019-06-29 09:28:28 +08:00
|
|
|
// The recommended way to build Caddy involves
|
|
|
|
// creating a separate main module, which
|
|
|
|
// TODO: track related Go issue: https://github.com/golang/go/issues/29228
|
2019-07-13 00:15:27 +08:00
|
|
|
// once that issue is fixed, we should just be able to use bi.Main... hopefully.
|
|
|
|
for _, dep := range bi.Deps {
|
2019-12-30 04:16:34 +08:00
|
|
|
if dep.Path == ImportPath {
|
2019-08-18 09:14:55 +08:00
|
|
|
return dep
|
2019-06-29 09:28:28 +08:00
|
|
|
}
|
|
|
|
}
|
2019-08-18 09:14:55 +08:00
|
|
|
return &bi.Main
|
2019-06-29 09:28:28 +08:00
|
|
|
}
|
2019-07-13 00:15:27 +08:00
|
|
|
return mod
|
2019-06-29 09:28:28 +08:00
|
|
|
}
|
|
|
|
|
2019-04-12 10:42:55 +08:00
|
|
|
// CtxKey is a value type for use with context.WithValue.
|
|
|
|
type CtxKey string
|
2019-04-08 14:00:14 +08:00
|
|
|
|
2019-11-05 03:05:20 +08:00
|
|
|
// This group of variables pertains to the current configuration.
|
2019-04-08 14:00:14 +08:00
|
|
|
var (
|
2019-11-05 03:05:20 +08:00
|
|
|
// currentCfgMu protects everything in this var block.
|
2019-04-26 03:54:48 +08:00
|
|
|
currentCfgMu sync.RWMutex
|
2019-11-05 03:05:20 +08:00
|
|
|
|
|
|
|
// currentCfg is the currently-running configuration.
|
|
|
|
currentCfg *Config
|
|
|
|
|
|
|
|
// rawCfg is the current, generic-decoded configuration;
|
|
|
|
// we initialize it as a map with one field ("config")
|
|
|
|
// to maintain parity with the API endpoint and to avoid
|
|
|
|
// the special case of having to access/mutate the variable
|
|
|
|
// directly without traversing into it.
|
|
|
|
rawCfg = map[string]interface{}{
|
|
|
|
rawConfigKey: nil,
|
|
|
|
}
|
|
|
|
|
|
|
|
// rawCfgJSON is the JSON-encoded form of rawCfg. Keeping
|
|
|
|
// this around avoids an extra Marshal call during changes.
|
|
|
|
rawCfgJSON []byte
|
|
|
|
|
|
|
|
// rawCfgIndex is the map of user-assigned ID to expanded
|
|
|
|
// path, for converting /id/ paths to /config/ paths.
|
|
|
|
rawCfgIndex map[string]string
|
2019-04-08 14:00:14 +08:00
|
|
|
)
|
2019-12-30 04:16:34 +08:00
|
|
|
|
|
|
|
// ImportPath is the package import path for Caddy core.
|
|
|
|
const ImportPath = "github.com/caddyserver/caddy/v2"
|