search

cyberark / cyberark-conjur-cli

CyberArk Conjur command line interface written in Python
https://www.conjur.org
Apache License 2.0
17 stars 16 forks source link

Init command #79

Closed InbalZilberman closed 3 years ago

InbalZilberman commented 3 years ago

Feature Overview & Customer Need

As a Conjur user I would like to configure my work env once In order to perform the actions I like most in Conjur against the same environment and not retype them again

The init command help will look as follows NAME init - Initialize the Conjur configuration

SYNOPSIS conjur [global options] init [command options]

COMMAND OPTIONS -a, --account=arg - Conjur organization account name (will be obtained from host unless provided by this option) (default: none) Dont ask for account in init if there is only one account in the conjur you are running against -c, --certificate=arg - Conjur SSL certificate (will be obtained from host unless provided by this option) (default: none) -f, --file=FILE - File to write the configuration to (default: none) --force=arg - Force overwrite of existing files (default: none) -u, --url=URL - URL of the Conjur service (default: none)

The bolded line is a change from behavior from what is provided today in our Ruby CLI

The common use case will be

conjur init --url

Where is the URL of the Conjur/DAP Server in the following format https://.

Same UX as today in Ruby CLI - Except of 2 thins:

  1. The account becomes not mandatory and should be taken from info of the node if possible
  2. We will not accept the cert by default but will make sure the user explicitly type yes to accept the cert. By default we will consider the response to be NO. That way we are making sure the user is well aware of his/her action. Kinda like EULA

As a result

  1. The cert pem file is created if not provided
  2. a file named.conjurrc is created with the Conjur env parameters:

---

account: XXX

plugins: []

appliance_url: https://

cert_file: "/path/for/cert.pem"

open issue

Do we need plugins? lets make sure we understand what is provided in Ruby CLI

Security

Can we implement this statement we give in our docs (also below) today?

NOTE: Conjur uses a persistent .netrc file by default and for convenience. For a more secure setup, we recommend that you change .conjurrc by adding a directive netrc_path pointing to a file in the /dev/shm directory (on the OSes that support such a filesystem). This way, credentials and authentication context are wiped out automatically on each reboot, and also are not part of any disk snapshots of the working environment.

open issue

  1. Do we need to remove the insecure option from the init?
  2. Who should have permissions to .conjurrc?

Process logic and Demo

Conjur use with a machine that the Python CLI already been installed in now runs

`conjur init --url <conjur-appliance-hostname>

he is able to run other commands conjur python cli on this env like login and so on

User messages

All user messages that are part of init today in Ruby CLI should remain the same.

If more than 2 accounts are provided an error should be given to ask the user to provide the account

Documentation

Please provide enhance documentation in online help and readme

DOD

sgnn7 commented 3 years ago

@InbalZilberman It may be good to also take a look at this issue and the related WIP covering the improvement work of the current conjur init UX.

sharonr78 commented 3 years ago

Thanks @InbalZilberman, a few comments:

  1. In general, I'd prefer to use "Usage" or "Syntax" in our CLI's help, over "Synopsis", as it better describes the structure of the command and its parts, while "synopsis" is more suitable for a brief summary / outline / survey (e.g. in long man command).
  2. I suggest to drop the equal sign after a flag, so it would be like so: conjur init -a arg. It makes it more readable IMO.
  3. Why do we need to indicate a "none" default? it's better to indicate it only when there is a default, e.g., (default: logged-in user). I think it makes it confusing for all options.
  4. A short form is also required for --force. We can use -F. Another option is to use -o, --overwrite instead of force.
  5. The of format --url should be indicated in the command option's explanation, like so: -u, --url=URL - URL of the Conjur service (format: https://..)
  6. We should add an example in the end of the command's help, like so: conjur init -a myorg -c /tmp/cert.pem -f /tmp/conjur.config -o -u https://<conjur server>
  7. I think we should provide an output when init is executed. This will be a good feedback for the user's configuration. The command can output this kind of message: Conjur configuration initialized successfully! A file named .conjurrc was created with Conjur's environment parameters: account: XXX plugins: XXX Appliance URL: https://<Conjur_host_name> Certificate file: </path/for/cert.pem>
izgeri commented 3 years ago

Can we also please include in this issue a description of how this changes the UX of the current Python CLI? It's not clear to me from what I'm reading on this page.

If I understand correctly, at current the Python CLI does not support the ability to persist configurations, and you supply the full configuration each time you run a CLI command using flags. There is a rough sketch of a proposed implementation for persisting Conjur configurations here: https://github.com/cyberark/conjur-api-python3/issues/11. In this issue, we plan to add a CLI command to initialize a stored configuration.

Does that sound right? Is init the right name for this command? Do we intend to only support one Conjur configuration, or could a person have multiple Conjur configurations on their machine? Would this command handle both adding a new config and switching configs? If we don't support having multiple configurations, can we be clear about that in this command - that it sets the Conjur configuration and overwrites any existing configurations? If we do support multiple configs, is there a way to use this command to point to an existing config file so that future CLI commands will use the config from that file?

It looks like here we are taking the command name init from the old Ruby CLI, but it's worth questioning what init means in this context and whether it is clear enough.

Some other CLI examples to consider:

sgnn7 commented 3 years ago

One thing to note that we do support ~/.netrc and ~/.conjurrc currently in the CLI

sigalsax commented 3 years ago

@InbalZilberman can you move that security point of netrc to the authn epic? It has more to do with the authn then conjurrc

sharonr78 commented 3 years ago

After reading @izgeri comments and talk to @InbalZilberman I really think that it worth changing the command's name from init to config. It sounds much better as it actually configures the environment (.conjurrc). So it’ll look like so: conjur config -a my_org -u https://localhost. We can do that in later phases, but worth thinking about it.

sigalsax commented 3 years ago

@sharonr78 config or configure? I personally like configure

Important to note that we cannot change the command terms after phase 1 because they will lead to breaking changes for other developers that use our client in their code and also will be changing the experience for the user which I strongly recommend against. I agree that init is not intuitive so let's discuss this in our next meeting

InbalZilberman commented 3 years ago

@sigalsax following the url question If the user choose to provide http uri than a warning will be given to the user

sigalsax commented 3 years ago