Open qrkourier opened 10 months ago
This will make it significantly easier to follow the best practice of using certificate authenticators with the mgmt API instead of an admin password.
The --cli-identity
option will be too confusing after we add an --identity
option to log in with a Ziti-standard identity JSON file. Instead, --cli-identity
could become --profile
or --cli-profile
because the value is an arbitrary profile name on the local system, not the name of a Ziti identity entity nor the path to a Ziti identity file.
❯ ziti edge login --help
login allows the ziti command to establish a session with a Ziti Edge Controller, allowing more commands to be run against the controller.
Usage:
ziti edge login my.controller.hostname[:port]/path [flags]
Flags:
--ca string additional root certificates used by the Ziti Edge Controller
-i, --cli-identity string Specify the saved identity you want the CLI to use when connect to the controller with
-c, --client-cert string A certificate used to authenticate
-k, --client-key string The key to use with certificate authentication
-e, --ext-jwt string A file containing a JWT from an external provider to be used for authentication
-h, --help help for login
--ignore-config If set, does not use value from the config file for hostname or username. Values must be entered or will be prompted for.
-j, --output-json Output the full JSON response from the Ziti Edge Controller
--output-request-json Output the full JSON request to the Ziti Edge Controller
-p, --password string password to use for authenticating to the Ziti Edge Controller, if -u is supplied and -p is not, a value will be prompted for
--read-only marks this login as read-only. Note: this is not a guarantee that nothing can be changed on the server. Care should still be taken!
--timeout int Timeout for REST operations (specified in seconds) (default 5)
-t, --token string if an api token has already been acquired, it can be set in the config with this option. This will set the session to read only by default
-u, --username string username to use for authenticating to the Ziti Edge Controller
--verbose Enable verbose logging
-y, --yes If set, responds to prompts with yes. This will result in untrusted certs being accepted or updated.
@qrkourier I would love to have an alternative to the current password-only login method! Another point, not 100% directly related would be to have special non-expiring API tokens, which is the problem I was facing with the openziti_exporter.
@mjtrangoni While this issue is being worked you can use this approach to log in as an administrator without a password. You must create the identity with the --admin
flag.
The ziti
CLI has a built-in facility for separating that standard Identity file format into its components.
ziti ops unwrap \
--cert /tmp/admin-with-cert-auth.cert \
--key /tmp/admin-with-cert-auth.key \
--ca /tmp/admin-with-cert-auth.ca
then
ziti edge login miniziti-controller.192.168.49.2.sslip.io:443 \
--username admin-with-cert-auth \
--client-cert /tmp/admin-with-cert-auth.cert \
--client-key /tmp/admin-with-cert-auth.key \
--ca /tmp/admin-with-cert-auth.ca
and external JWT signers
Summary: This feature is partially implemented. The next steps are to enable OIDC and fix a bug where the token is cached with an incorrect management API URL.
issue for this bug: https://github.com/openziti/ziti/issues/2451
ziti edge login ziti.example.com --file ./admin2.json;
jq '.edgeIdentities.default.url = "https://ziti.example.com:443/edge/management/v1"' ~/.config/ziti/ziti-cli.json | tee /tmp/ziti-cli.json;
mv /tmp/ziti-cli.json ~/.config/ziti/ziti-cli.json
The easiest way to obtain an admin client cert is to enroll the JWT with the CLI. This produces a Ziti-standard JSON file with the identity's context, including the cert, key, and trust bundle.
Before using that identity with
ziti edge login --client-cert
, it's currently necessary to first unpack the enrolled context file into its component parts: cert, key, and bundle, e.g.ziti ops unwrap ./ziti-id.json
produces./cert
,./key
, and./ca
PEM files.This unwrap step would be superfluous if the ziti CLI could use its own Ziti-standard JSON file like this
ziti edge login --identity ./ziti-id.json
.This issue is peeled off from a comment in a related issue https://github.com/openziti/ziti/issues/127#issuecomment-1675180719