Add bash completion script and automate `.cap` file lookup for for ocluster-admin

[shonfeder]

@mtelvers has a nice setup to streamline the use of the ocluster-admin. As a low priority way to improve operator quality of life and achieve some "documentation by automation" it could be cool to incorporate parts of these into the CLI and installation procedure.

But in the meantime, I'll just include the scripts her shared with me here, as this at least makes them available for others who may find them useful:

To avoid having to supply the path to an admin.cap wile, you can make a runner script like /usr/local/bin/ci3-admin

#!/bin/bash

ocluster-admin -c ~/.config/ocluster/admin.cap "$@"

Then get bash completions with this script added to, e.g., /etc/bash_completion.d/ci3-admin

#/usr/bin/env bash
_ci3-admin_completions()
{
  WORDS=()
  for value in "${COMP_WORDS[@]}"; do
    [[ $value != --* ]] && WORDS+=($value)
  done

  if [ "${#WORDS[@]}" == "2" ]; then
    COMPREPLY=($(compgen -W "$(ci3-admin  2>&1 | head -1 | grep -Po "'\K[^', .]*")" -- "${WORDS[1]}"))
    return
  fi

  if [ "${#WORDS[@]}" == "3" ]; then
    case ${WORDS[1]} in
      show|pause|unpause|exec|forget|set-rate|update)
        COMPREPLY=($(compgen -W "$(ci3-admin show)" -- "${WORDS[2]}"))
        ;;
    esac
    return
  fi

  if [ "${#WORDS[@]}" == "4" ]; then
    case ${WORDS[1]} in
      pause|unpause|forget|update)
        COMPREPLY=($(compgen -W "$(ci3-admin show ${WORDS[2]} --terse)" -- "${WORDS[3]}"))
        ;;
    esac
    return
  fi
}

complete -F _ci3-admin_completions ci3-admin

Including this in the installation and CLI might mean:

• Extend the CLI so that ocluster-admint looks in particular location for the admin.cap file ("convention over configuration")
• Add the auto-completion script to the installation recipe.

[talex5]

To avoid having to supply the path to an admin.cap wile, you can make a runner script like /usr/local/bin/ci3-admin

The README already suggests setting an alias for this. Some shells (e.g. fish) let you make this persistent easily using alias --save ..., which is easier than creating a script manually, and tab-completion continues to work when using the alias.

Using a fixed location for admin.cap has a couple of problems:

First, if you have a single cluster then it saves you one alias command over your lifetime, but if you have e.g. production and staging clusters then you need a separate set of instructions for that.

The other (more theoretical) issue is that defining an alias tells the shell that you want the alias to have access to the cap file with the access token. If instead ocluster-admin hard-codes the location then either:

a) You need to mess around with your security policy to grant ocluster-admin access to the secret, or
b) Your computer needs to be set up so that every program you run has access to all secrets, just in case.

Now I appreciate that our species has collectively decided that (b) is just fine for now, but I still live in hope that mainstream shells will one day work more sensibly...

[shonfeder]

First, if you have a single cluster then it saves you one alias command over your lifetime, but if you have e.g. production and staging clusters then you need a separate set of instructions for that.

I think this could be addressed by allowing an override via CLI or config file. ssh's behavior seems like a decent example here.

The other (more theoretical) issue is that defining an alias tells the shell that you want the alias to have access to the cap file with the access token. If instead ocluster-admin hard-codes the location then either:

a) You need to mess around with your security policy to grant ocluster-admin access to the secret, or

Do we not have decent examples of how to solve this problem we could draw from? Again, ssh comes to mind. In any case, I don't see this as being a problem addressed by the current UI, but maybe I am missing something.

b) Your computer needs to be set up so that every program you run has access to all secrets, just in case.

Now I appreciate that our species has collectively decided that (b) is just fine for now, but I still live in hope that mainstream shells will one day work more sensibly...

I'm all for improved security (not using a single shared admin.cap file for a cluster seems like it could be an important improvement, for instance)! However, this latter issues you raise seems orthogonal to my suggestion, afaict. Could you maybe help me understand better? This might help: do you currently have things configured on your machine in such a way that use of a defined alas to pass the admin secret is giving you security guarantees you'd lose if the program checked in, e.g., .config/ocluster by default?

[talex5]

Do we not have decent examples of how to solve this problem we could draw from?

Well, this is the solution: programs should only be able to access things passed to them by the user. For example, I can upload a file to a web-page by dragging it into the browser window, but the web-page can't just load whatever files it wants.

Again, ssh comes to mind.

ssh doesn't directly solve this problem (any program can read your ~/.ssh/id_rsa by default), though you can use an agent, which might help.

do you currently have things configured on your machine in such a way that use of a defined alas to pass the admin secret is giving you security guarantees you'd lose if the program checked in, e.g., .config/ocluster by default?

No, sadly (which is why I say this benefit is only theoretical). Plash (the Principle of Least Authority shell) worked that way, but it was never complete enough to use as your default shell, and is no longer maintained.

Anyway, I'm just giving some background on why it's designed the way it is. Basically, I think the whole idea of running programs and having them find their configuration was a mistake - it makes more sense to run a configuration and have it load the program instead.