2017-06-20 14:41:40 -04:00
|
|
|
package swarm
|
|
|
|
|
|
|
|
import (
|
|
|
|
"bytes"
|
2022-02-25 08:32:11 -05:00
|
|
|
"io"
|
2017-07-12 14:44:47 -04:00
|
|
|
"os"
|
2017-06-20 14:41:40 -04:00
|
|
|
"testing"
|
|
|
|
"time"
|
|
|
|
|
2017-08-21 16:30:09 -04:00
|
|
|
"github.com/docker/cli/internal/test"
|
2017-06-20 14:41:40 -04:00
|
|
|
"github.com/docker/docker/api/types/swarm"
|
2020-02-22 12:12:14 -05:00
|
|
|
"gotest.tools/v3/assert"
|
|
|
|
is "gotest.tools/v3/assert/cmp"
|
2017-06-20 14:41:40 -04:00
|
|
|
)
|
|
|
|
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
const (
|
|
|
|
cert = `
|
|
|
|
-----BEGIN CERTIFICATE-----
|
|
|
|
MIIBuDCCAV4CCQDOqUYOWdqMdjAKBggqhkjOPQQDAzBjMQswCQYDVQQGEwJVUzEL
|
|
|
|
MAkGA1UECAwCQ0ExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDzANBgNVBAoMBkRv
|
|
|
|
Y2tlcjEPMA0GA1UECwwGRG9ja2VyMQ0wCwYDVQQDDARUZXN0MCAXDTE4MDcwMjIx
|
|
|
|
MjkxOFoYDzMwMTcxMTAyMjEyOTE4WjBjMQswCQYDVQQGEwJVUzELMAkGA1UECAwC
|
|
|
|
Q0ExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDzANBgNVBAoMBkRvY2tlcjEPMA0G
|
|
|
|
A1UECwwGRG9ja2VyMQ0wCwYDVQQDDARUZXN0MFkwEwYHKoZIzj0CAQYIKoZIzj0D
|
|
|
|
AQcDQgAEgvvZl5Vqpr1e+g5IhoU6TZHgRau+BZETVFTmqyWYajA/mooRQ1MZTozu
|
|
|
|
s9ZZZA8tzUhIqS36gsFuyIZ4YiAlyjAKBggqhkjOPQQDAwNIADBFAiBQ7pCPQrj8
|
|
|
|
8zaItMf0pk8j1NU5XrFqFEZICzvjzUJQBAIhAKq2gFwoTn8KH+cAAXZpAGJPmOsT
|
|
|
|
zsBT8gBAOHhNA6/2
|
|
|
|
-----END CERTIFICATE-----`
|
|
|
|
key = `
|
|
|
|
-----BEGIN EC PRIVATE KEY-----
|
|
|
|
MHcCAQEEICyheZpw70pbgO4hEuwhZTETWyTpNJmJ3TyFaWT6WTRkoAoGCCqGSM49
|
|
|
|
AwEHoUQDQgAEgvvZl5Vqpr1e+g5IhoU6TZHgRau+BZETVFTmqyWYajA/mooRQ1MZ
|
|
|
|
Tozus9ZZZA8tzUhIqS36gsFuyIZ4YiAlyg==
|
|
|
|
-----END EC PRIVATE KEY-----`
|
|
|
|
)
|
|
|
|
|
2017-06-20 14:41:40 -04:00
|
|
|
func swarmSpecWithFullCAConfig() *swarm.Spec {
|
|
|
|
return &swarm.Spec{
|
|
|
|
CAConfig: swarm.CAConfig{
|
|
|
|
SigningCACert: "cacert",
|
|
|
|
SigningCAKey: "cakey",
|
|
|
|
ForceRotate: 1,
|
|
|
|
NodeCertExpiry: time.Duration(200),
|
|
|
|
ExternalCAs: []*swarm.ExternalCA{
|
|
|
|
{
|
|
|
|
URL: "https://example.com/ca",
|
|
|
|
Protocol: swarm.ExternalCAProtocolCFSSL,
|
|
|
|
CACert: "excacert",
|
|
|
|
},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestDisplayTrustRootNoRoot(t *testing.T) {
|
|
|
|
buffer := new(bytes.Buffer)
|
|
|
|
err := displayTrustRoot(buffer, swarm.Swarm{})
|
2018-03-06 15:54:24 -05:00
|
|
|
assert.Error(t, err, "No CA information available")
|
2017-06-20 14:41:40 -04:00
|
|
|
}
|
|
|
|
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
type invalidCATestCases struct {
|
|
|
|
args []string
|
|
|
|
errorMsg string
|
|
|
|
}
|
|
|
|
|
|
|
|
func writeFile(data string) (string, error) {
|
2022-02-25 08:32:11 -05:00
|
|
|
tmpfile, err := os.CreateTemp("", "testfile")
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
|
|
|
_, err = tmpfile.Write([]byte(data))
|
|
|
|
if err != nil {
|
|
|
|
return "", err
|
|
|
|
}
|
2022-02-25 08:32:11 -05:00
|
|
|
return tmpfile.Name(), tmpfile.Close()
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
}
|
|
|
|
|
2017-07-12 14:44:47 -04:00
|
|
|
func TestDisplayTrustRootInvalidFlags(t *testing.T) {
|
|
|
|
// we need an actual PEMfile to test
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
tmpfile, err := writeFile(cert)
|
2018-03-06 14:44:13 -05:00
|
|
|
assert.NilError(t, err)
|
2022-02-25 08:32:11 -05:00
|
|
|
t.Cleanup(func() { _ = os.Remove(tmpfile) })
|
2017-07-12 14:44:47 -04:00
|
|
|
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
errorTestCases := []invalidCATestCases{
|
2017-07-12 14:44:47 -04:00
|
|
|
{
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
args: []string{"--ca-cert=" + tmpfile},
|
|
|
|
errorMsg: "flag requires the `--rotate` flag to update the CA",
|
2017-07-12 14:44:47 -04:00
|
|
|
},
|
|
|
|
{
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
args: []string{"--ca-key=" + tmpfile},
|
|
|
|
errorMsg: "flag requires the `--rotate` flag to update the CA",
|
2017-07-12 14:44:47 -04:00
|
|
|
},
|
|
|
|
{ // to make sure we're not erroring because we didn't provide a CA key along with the CA cert
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
args: []string{
|
|
|
|
"--ca-cert=" + tmpfile,
|
|
|
|
"--ca-key=" + tmpfile,
|
|
|
|
},
|
|
|
|
errorMsg: "flag requires the `--rotate` flag to update the CA",
|
2017-07-12 14:44:47 -04:00
|
|
|
},
|
|
|
|
{
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
args: []string{"--cert-expiry=2160h0m0s"},
|
|
|
|
errorMsg: "flag requires the `--rotate` flag to update the CA",
|
2017-07-12 14:44:47 -04:00
|
|
|
},
|
|
|
|
{
|
2021-04-30 03:31:41 -04:00
|
|
|
args: []string{"--external-ca=protocol=cfssl,url=https://some.example.com/https/url"},
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
errorMsg: "flag requires the `--rotate` flag to update the CA",
|
2017-07-12 14:44:47 -04:00
|
|
|
},
|
|
|
|
{ // to make sure we're not erroring because we didn't provide a CA cert and external CA
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
args: []string{
|
|
|
|
"--ca-cert=" + tmpfile,
|
2021-04-30 03:31:41 -04:00
|
|
|
"--external-ca=protocol=cfssl,url=https://some.example.com/https/url",
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
},
|
|
|
|
errorMsg: "flag requires the `--rotate` flag to update the CA",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
args: []string{
|
|
|
|
"--rotate",
|
2021-04-30 03:31:41 -04:00
|
|
|
"--external-ca=protocol=cfssl,url=https://some.example.com/https/url",
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
},
|
|
|
|
errorMsg: "rotating to an external CA requires the `--ca-cert` flag to specify the external CA's cert - " +
|
|
|
|
"to add an external CA with the current root CA certificate, use the `update` command instead",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
args: []string{
|
|
|
|
"--rotate",
|
|
|
|
"--ca-cert=" + tmpfile,
|
|
|
|
},
|
|
|
|
errorMsg: "the --ca-cert flag requires that a --ca-key flag and/or --external-ca flag be provided as well",
|
2017-07-12 14:44:47 -04:00
|
|
|
},
|
|
|
|
}
|
|
|
|
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
for _, testCase := range errorTestCases {
|
2017-07-12 14:44:47 -04:00
|
|
|
cmd := newCACommand(
|
|
|
|
test.NewFakeCli(&fakeClient{
|
|
|
|
swarmInspectFunc: func() (swarm.Swarm, error) {
|
|
|
|
return swarm.Swarm{
|
|
|
|
ClusterInfo: swarm.ClusterInfo{
|
|
|
|
TLSInfo: swarm.TLSInfo{
|
|
|
|
TrustRoot: "root",
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}, nil
|
|
|
|
},
|
|
|
|
}))
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
assert.Check(t, cmd.Flags().Parse(testCase.args))
|
2022-02-25 08:32:11 -05:00
|
|
|
cmd.SetOut(io.Discard)
|
test spring-cleaning
This makes a quick pass through our tests;
Discard output/err
----------------------------------------------
Many tests were testing for error-conditions, but didn't discard output.
This produced a lot of noise when running the tests, and made it hard
to discover if there were actual failures, or if the output was expected.
For example:
=== RUN TestConfigCreateErrors
Error: "create" requires exactly 2 arguments.
See 'create --help'.
Usage: create [OPTIONS] CONFIG file|- [flags]
Create a config from a file or STDIN
Error: "create" requires exactly 2 arguments.
See 'create --help'.
Usage: create [OPTIONS] CONFIG file|- [flags]
Create a config from a file or STDIN
Error: error creating config
--- PASS: TestConfigCreateErrors (0.00s)
And after discarding output:
=== RUN TestConfigCreateErrors
--- PASS: TestConfigCreateErrors (0.00s)
Use sub-tests where possible
----------------------------------------------
Some tests were already set-up to use test-tables, and even had a usable
name (or in some cases "error" to check for). Change them to actual sub-
tests. Same test as above, but now with sub-tests and output discarded:
=== RUN TestConfigCreateErrors
=== RUN TestConfigCreateErrors/requires_exactly_2_arguments
=== RUN TestConfigCreateErrors/requires_exactly_2_arguments#01
=== RUN TestConfigCreateErrors/error_creating_config
--- PASS: TestConfigCreateErrors (0.00s)
--- PASS: TestConfigCreateErrors/requires_exactly_2_arguments (0.00s)
--- PASS: TestConfigCreateErrors/requires_exactly_2_arguments#01 (0.00s)
--- PASS: TestConfigCreateErrors/error_creating_config (0.00s)
PASS
It's not perfect in all cases (in the above, there's duplicate "expected"
errors, but Go conveniently adds "#01" for the duplicate). There's probably
also various tests I missed that could still use the same changes applied;
we can improve these in follow-ups.
Set cmd.Args to prevent test-failures
----------------------------------------------
When running tests from my IDE, it compiles the tests before running,
then executes the compiled binary to run the tests. Cobra doesn't like
that, because in that situation `os.Args` is taken as argument for the
command that's executed. The command that's tested now sees the test-
flags as arguments (`-test.v -test.run ..`), which causes various tests
to fail ("Command XYZ does not accept arguments").
# compile the tests:
go test -c -o foo.test
# execute the test:
./foo.test -test.v -test.run TestFoo
=== RUN TestFoo
Error: "foo" accepts no arguments.
The Cobra maintainers ran into the same situation, and for their own
use have added a special case to ignore `os.Args` in these cases;
https://github.com/spf13/cobra/blob/v1.8.1/command.go#L1078-L1083
args := c.args
// Workaround FAIL with "go test -v" or "cobra.test -test.v", see #155
if c.args == nil && filepath.Base(os.Args[0]) != "cobra.test" {
args = os.Args[1:]
}
Unfortunately, that exception is too specific (only checks for `cobra.test`),
so doesn't automatically fix the issue for other test-binaries. They did
provide a `cmd.SetArgs()` utility for this purpose
https://github.com/spf13/cobra/blob/v1.8.1/command.go#L276-L280
// SetArgs sets arguments for the command. It is set to os.Args[1:] by default, if desired, can be overridden
// particularly useful when testing.
func (c *Command) SetArgs(a []string) {
c.args = a
}
And the fix is to explicitly set the command's args to an empty slice to
prevent Cobra from falling back to using `os.Args[1:]` as arguments.
cmd := newSomeThingCommand()
cmd.SetArgs([]string{})
Some tests already take this issue into account, and I updated some tests
for this, but there's likely many other ones that can use the same treatment.
Perhaps the Cobra maintainers would accept a contribution to make their
condition less specific and to look for binaries ending with a `.test`
suffix (which is what compiled binaries usually are named as).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2024-07-03 19:29:04 -04:00
|
|
|
cmd.SetErr(io.Discard)
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
assert.ErrorContains(t, cmd.Execute(), testCase.errorMsg)
|
2017-07-12 14:44:47 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-20 14:41:40 -04:00
|
|
|
func TestDisplayTrustRoot(t *testing.T) {
|
|
|
|
buffer := new(bytes.Buffer)
|
|
|
|
trustRoot := "trustme"
|
|
|
|
err := displayTrustRoot(buffer, swarm.Swarm{
|
|
|
|
ClusterInfo: swarm.ClusterInfo{
|
|
|
|
TLSInfo: swarm.TLSInfo{TrustRoot: trustRoot},
|
|
|
|
},
|
|
|
|
})
|
2018-03-05 18:53:52 -05:00
|
|
|
assert.NilError(t, err)
|
|
|
|
assert.Check(t, is.Equal(trustRoot+"\n", buffer.String()))
|
2017-06-20 14:41:40 -04:00
|
|
|
}
|
|
|
|
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
type swarmUpdateRecorder struct {
|
|
|
|
spec swarm.Spec
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s *swarmUpdateRecorder) swarmUpdate(sp swarm.Spec, _ swarm.UpdateFlags) error {
|
|
|
|
s.spec = sp
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func swarmInspectFuncWithFullCAConfig() (swarm.Swarm, error) {
|
|
|
|
return swarm.Swarm{
|
|
|
|
ClusterInfo: swarm.ClusterInfo{
|
|
|
|
Spec: *swarmSpecWithFullCAConfig(),
|
|
|
|
},
|
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
2017-06-20 14:41:40 -04:00
|
|
|
func TestUpdateSwarmSpecDefaultRotate(t *testing.T) {
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
s := &swarmUpdateRecorder{}
|
|
|
|
cli := test.NewFakeCli(&fakeClient{
|
|
|
|
swarmInspectFunc: swarmInspectFuncWithFullCAConfig,
|
|
|
|
swarmUpdateFunc: s.swarmUpdate,
|
|
|
|
})
|
|
|
|
cmd := newCACommand(cli)
|
|
|
|
cmd.SetArgs([]string{"--rotate", "--detach"})
|
2020-05-07 08:25:59 -04:00
|
|
|
cmd.SetOut(cli.OutBuffer())
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
assert.NilError(t, cmd.Execute())
|
2017-06-20 14:41:40 -04:00
|
|
|
|
|
|
|
expected := swarmSpecWithFullCAConfig()
|
|
|
|
expected.CAConfig.ForceRotate = 2
|
|
|
|
expected.CAConfig.SigningCACert = ""
|
|
|
|
expected.CAConfig.SigningCAKey = ""
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
assert.Check(t, is.DeepEqual(*expected, s.spec))
|
2017-06-20 14:41:40 -04:00
|
|
|
}
|
|
|
|
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
func TestUpdateSwarmSpecCertAndKey(t *testing.T) {
|
|
|
|
certfile, err := writeFile(cert)
|
|
|
|
assert.NilError(t, err)
|
|
|
|
defer os.Remove(certfile)
|
|
|
|
|
|
|
|
keyfile, err := writeFile(key)
|
|
|
|
assert.NilError(t, err)
|
|
|
|
defer os.Remove(keyfile)
|
|
|
|
|
|
|
|
s := &swarmUpdateRecorder{}
|
|
|
|
cli := test.NewFakeCli(&fakeClient{
|
|
|
|
swarmInspectFunc: swarmInspectFuncWithFullCAConfig,
|
|
|
|
swarmUpdateFunc: s.swarmUpdate,
|
2017-06-20 14:41:40 -04:00
|
|
|
})
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
cmd := newCACommand(cli)
|
|
|
|
cmd.SetArgs([]string{
|
|
|
|
"--rotate",
|
|
|
|
"--detach",
|
|
|
|
"--ca-cert=" + certfile,
|
|
|
|
"--ca-key=" + keyfile,
|
2022-09-29 11:21:51 -04:00
|
|
|
"--cert-expiry=3m",
|
|
|
|
})
|
2020-05-07 08:25:59 -04:00
|
|
|
cmd.SetOut(cli.OutBuffer())
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
assert.NilError(t, cmd.Execute())
|
2017-06-20 14:41:40 -04:00
|
|
|
|
|
|
|
expected := swarmSpecWithFullCAConfig()
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
expected.CAConfig.SigningCACert = cert
|
|
|
|
expected.CAConfig.SigningCAKey = key
|
|
|
|
expected.CAConfig.NodeCertExpiry = 3 * time.Minute
|
|
|
|
assert.Check(t, is.DeepEqual(*expected, s.spec))
|
2017-06-20 14:41:40 -04:00
|
|
|
}
|
|
|
|
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
func TestUpdateSwarmSpecCertAndExternalCA(t *testing.T) {
|
|
|
|
certfile, err := writeFile(cert)
|
|
|
|
assert.NilError(t, err)
|
|
|
|
defer os.Remove(certfile)
|
|
|
|
|
|
|
|
s := &swarmUpdateRecorder{}
|
|
|
|
cli := test.NewFakeCli(&fakeClient{
|
|
|
|
swarmInspectFunc: swarmInspectFuncWithFullCAConfig,
|
|
|
|
swarmUpdateFunc: s.swarmUpdate,
|
2017-06-20 14:41:40 -04:00
|
|
|
})
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
cmd := newCACommand(cli)
|
|
|
|
cmd.SetArgs([]string{
|
|
|
|
"--rotate",
|
|
|
|
"--detach",
|
|
|
|
"--ca-cert=" + certfile,
|
2022-09-29 11:21:51 -04:00
|
|
|
"--external-ca=protocol=cfssl,url=https://some.external.ca.example.com",
|
|
|
|
})
|
2020-05-07 08:25:59 -04:00
|
|
|
cmd.SetOut(cli.OutBuffer())
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
assert.NilError(t, cmd.Execute())
|
2017-06-20 14:41:40 -04:00
|
|
|
|
|
|
|
expected := swarmSpecWithFullCAConfig()
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
expected.CAConfig.SigningCACert = cert
|
|
|
|
expected.CAConfig.SigningCAKey = ""
|
|
|
|
expected.CAConfig.ExternalCAs = []*swarm.ExternalCA{
|
|
|
|
{
|
|
|
|
Protocol: swarm.ExternalCAProtocolCFSSL,
|
2021-04-30 03:31:41 -04:00
|
|
|
URL: "https://some.external.ca.example.com",
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
CACert: cert,
|
|
|
|
Options: make(map[string]string),
|
|
|
|
},
|
|
|
|
}
|
|
|
|
assert.Check(t, is.DeepEqual(*expected, s.spec))
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestUpdateSwarmSpecCertAndKeyAndExternalCA(t *testing.T) {
|
|
|
|
certfile, err := writeFile(cert)
|
|
|
|
assert.NilError(t, err)
|
|
|
|
defer os.Remove(certfile)
|
|
|
|
|
|
|
|
keyfile, err := writeFile(key)
|
|
|
|
assert.NilError(t, err)
|
|
|
|
defer os.Remove(keyfile)
|
|
|
|
|
|
|
|
s := &swarmUpdateRecorder{}
|
|
|
|
cli := test.NewFakeCli(&fakeClient{
|
|
|
|
swarmInspectFunc: swarmInspectFuncWithFullCAConfig,
|
|
|
|
swarmUpdateFunc: s.swarmUpdate,
|
|
|
|
})
|
|
|
|
cmd := newCACommand(cli)
|
|
|
|
cmd.SetArgs([]string{
|
|
|
|
"--rotate",
|
|
|
|
"--detach",
|
|
|
|
"--ca-cert=" + certfile,
|
|
|
|
"--ca-key=" + keyfile,
|
2022-09-29 11:21:51 -04:00
|
|
|
"--external-ca=protocol=cfssl,url=https://some.external.ca.example.com",
|
|
|
|
})
|
2020-05-07 08:25:59 -04:00
|
|
|
cmd.SetOut(cli.OutBuffer())
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
assert.NilError(t, cmd.Execute())
|
|
|
|
|
|
|
|
expected := swarmSpecWithFullCAConfig()
|
|
|
|
expected.CAConfig.SigningCACert = cert
|
|
|
|
expected.CAConfig.SigningCAKey = key
|
|
|
|
expected.CAConfig.ExternalCAs = []*swarm.ExternalCA{
|
|
|
|
{
|
|
|
|
Protocol: swarm.ExternalCAProtocolCFSSL,
|
2021-04-30 03:31:41 -04:00
|
|
|
URL: "https://some.external.ca.example.com",
|
Propagate the provided external CA certificate to the external CA object
in swarm.
Also, fix some CLI command confusions:
1. If the --external-ca flag is provided, require a --ca-cert flag as well, otherwise
the external CA is set but the CA certificate is actually rotated to an internal
cert
2. If a --ca-cert flag is provided, require a --ca-key or --external-ca flag be
provided as well, otherwise either the server will say that the request is
invalid, or if there was previously an external CA corresponding to the cert, it
will succeed. While that works, it's better to require the user to explicitly
set all the parameters of the new desired root CA.
This also changes the `swarm update` function to set the external CA's CACert field,
which while not strictly necessary, makes the CA list more explicit.
Signed-off-by: Ying Li <ying.li@docker.com>
2018-07-02 19:53:23 -04:00
|
|
|
CACert: cert,
|
|
|
|
Options: make(map[string]string),
|
|
|
|
},
|
|
|
|
}
|
|
|
|
assert.Check(t, is.DeepEqual(*expected, s.spec))
|
2017-06-20 14:41:40 -04:00
|
|
|
}
|