allow full url in client

[bigangryrobot]

This references issue #60 and is simply changing the server flag with a URL flag. Like as is shown in the updated help text, the user can put in a http or https fqdn

This pr is lower risk due to it only being referenced here https://github.com/megaease/easegress/blob/7bae03f5f33be47a9bf8836275b6c71e9f405712/cmd/client/command/common.go#L108 and here https://github.com/megaease/easegress/blob/7bae03f5f33be47a9bf8836275b6c71e9f405712/cmd/client/main.go#L116

Lastly, here is the output from the local test

A command line admin tool for Easegress.

Usage:
  egctl [command]

Examples:
  # List APIs.
  egctl api list

  # Probe health.
  egctl health

  # List member information.
  egctl member list

  # Purge a easegress member
  egctl member purge <member name>

  # List object kinds.
  egctl object kinds

  # Create an object from a yaml file.
  egctl object create -f <object_spec.yaml>

  # Create an object from stdout.
  cat <object_spec.yaml> | egctl object create

  # Delete an object.
  egctl object delete <object_name>

  # Get an object.
  egctl object get <object_name>

  # List objects.
  egctl object list

  # Update an object from a yaml file.
  egctl object update -f <new_object_spec.yaml>

  # Update an object from stdout.
  cat <new_object_spec.yaml> | egctl object update

  # list objects status
  egctl object status list

  # Get object status
  egctl object status get <object_name>


Available Commands:
  api         View Easegress APIs
  completion  Output shell completion code for the specified shell (bash or zsh)
  health      Probe Easegress health
  help        Help about any command
  member      View Easegress members
  mesh        deploy and manager mesh components
  object      View and change objects

Flags:
  -h, --help            help for egctl
  -o, --output string   Output format(json, yaml) (default "yaml")
      --url string      The address of the Easegress endpoint (default "https://localhost:2381")

Use "egctl [command] --help" for more information about a command.

[xxx7xxxx]

Here are my opinions:

1. For now plain HTTP is acceptable for admin interfaces.
2. If we decide to support HTTPS or gRPC(like etcd3.x), it got more work. e.g. certificates stuff for HTTPS, protobuf definition for gRPC and so on.

[zhao-kun]

I think HTTP should be deprecated HTTPS might bring complicated in the operation, but it's an enterprise feature for providing more security and worth our while to try it. So @benja-wu can schedule this to the Easegress' roadmap.

[benja-wu]

I think HTTP should be deprecated HTTPS might bring complicated in the operation, but it's an enterprise feature for providing more security and worth our while to try it. So @benja-wu can schedule this to the Easegress' roadmap.

• I think we can keep the HTTP way for Admin APIs as default behavior, but support HTTPS as a new feature for enterprise's security purpose. Cause I believe that Easegress's admin API will be mostly invoked inside the company's local area network.
• Also I totally agree to support HTTPS in Admin APIs as an enterprise feature.

How about that?

[qdongxu]

It's necessary to clarify that we provide value-adding packages/features in the enterprise releases. but we don't disable the capability of the open-source releases. As in this case, It's good to let the cli tool supports https access. for the server-side, we can configure the admin port with SSL/TLS certificates out of the box(or provide a clear method, this can be planned in the roadmap). while the open-source users can configure by themselves (eg. put the API portal behind a gateway which enables https )

[bigangryrobot]

How the admin api is configured is fully separate from how it's accessed. Placing a loadbalancer in the path, or even using easegress its self to host the reverse to the admin api with ssl termination is incredibly easy.

The conversation here is simply, "Should the end user have flexibility in configuring the protocol as well as the endpoint", and I say absolutely

An admin api is no admin api without:

• an easy way to configure it (eg a config file because im an admin with x number of easegress instances)
• authn
• authz
  • audit logging
• https

[benja-wu]

How the admin api is configured is fully separate from how it's accessed. Placing a loadbalancer in the path, or even using easegress its self to host the reverse to the admin api with ssl termination is incredibly easy.

The conversation here is simply, "Should the end user have flexibility in configuring the protocol as well as the endpoint", and I say absolutely

An admin api is no admin api without:

• an easy way to configure it (eg a config file because im an admin with x number of easegress instances)

• authn

• authz

  • audit logging

• https

Hi @bigangryrobot ,

• Right now Easegress project had evolved into V.1.2.0. Many exciting features and inner implementation upgrades had been applied. Would u please come back and take a look at the brand new Easegress for supporting this Admin API security feature?

• Also we are looking forward to receiving your suggestions about the next direction Easegress should move at too.