gomeeseeks / meeseeks-box Goto Github PK

Because the help is getting big, so we should be able to ask for built-in commands explicitly, something like this:

help <- shows shell commands

help -all <- shows shell and built-in commands

As an initial implementation there are 3 permissions strategies:

• Any: any user can run the command
• User list: any user that is the command "allowed" list can execute the command
• None: no user can run the command (the default if it is not explicitly declared)

We should add a more complex permission model that allows to build a permission model.

For this to work we need to have real builtin commands that are not executed as a shell but that are understood by the box itself. Then we should be able to grant command execution grants to roles, and then group the users and grant the roles to the groups.

Such that:

• User
  • Has many groups
• Group
  • Has many roles
• Role
  • Has many granted commands

Then we will need builtin commands to:

• Grant a command to a role, and remove it.
• Grant a role to a group, and remove it.
• Join a user to a group, and remove it.

Some details to take into consideration

• Any username can be granted to anything, there is no need to keep accounts on the meeseeks-box, meaning that users don't have to create them (or admins)
• There should be a group that is setup in the configuration file indicating which are the admin users that have access to this set of builtin commands.
• There should be a way of regenerating the admin group, both in runtime and with the configuration file.
• We will need some form of persistency, the simplest one I can think of is slqite due to the simplicity of it.

Following on #76

We should accept the HUP signal to trigger a reload of the command configuration without impacting already running commands.

As a way of making it all visible, use a channel as the administration channel in which to report events, like when a client box joins the master, or when they are down, or when a permission is granted. Whatever matters.

This channel should be set in configuration and could also be an IM with a single user.

This will help with the agents by allowing users to be in full control of their commands configuration including who is allowed to execute these commands.

This is so because of groups are controlled at the server level, but commands can be controlled at the agent level.

This would allow having different command configurations depending on the channel in which the job is being invoked, allowing to do things like invoking from a staging environment to do something, and from a production environment to do something else.

My gut feeling is that the environment should be stored in the database (or in the configuration, if we want to keep agents fully isolated, else there's a risk of extracting an environment variable from the server this way) and that these environment values should be handled by admins.

The environment would be injected in the shell command right before execution, overriding any global environment configuration.

thoughts @omame @ilya-f ?

This is a complex one.

The idea is that we could start a meeseeks-box in remote mode, this will remove all the builtin commands and only allow to execute local commands, meaning that the box would not have any permission model, or even persistence.

This would require a token (or client cert) and will use grpc in streaming mode to talk to a master meeseeks-box to which it would register.

On connection the client box will register the "remote" commands on the master, and then the master will start directing commands to the remotes.

The master will then keep the permissions and the persistence of the remote commands execution, and will also use a heartbeat message to ensure that they are still there.

This way we can know how old is the current process.

This can then be reaped later when we start exporting Prometheus metrics.

https://rfc.zeromq.org/spec:42/C4/

I like it because of the no BS approach, wdyt? @omame

I just noticed that we don't have an issue for the labels, so here I am.

We're planning to add labels for the agents to fully leverage on remote mode. This way a user can target a set of agents by specifying a label selector when invoking a command.

One thing that I just thought. It would be great if we can also add an argument to target a subset of the resulting agents. For instance, target all front-end nodes but only run the command on one or three of them.

Instead of having a single monolithic YAML file with all the configuration, we should allow commands to be separated in multiple YAML files which can be either pointed at specifically or using a glob to register everything that would match a given path.

We should keep the old commands list which allows us to maintain backward compatibility, but we should add something like command_paths which would contain a list which should then be walked through and expanded to simplify registration.

Just run with coverage, and we are missing this one.

Currently it's returning all the log lines.

To allow checking what was executed when, and with which output, we should keep state of the executed commands, as they are started, and completed, and whenever a user wants to check the status.

This means that we need to add a set of builtin commands that enable to query commands like:

• status: (with id) returns the commands that are in flight right now. (or something like that, I can't think of a better command, honestly)
• status : returns the status of a command, status can be Running, Successful and Failed
• output : returns the execution message from the command, such that it prints the stdout/err if the command succeded or failed.

Requirements

• We will need to keep track of the commands in some form of persistence for the command metadata, the best for this is sqlite for simplicity.
• We will need to keep track of the output of the commands, for this the best is simply the filesystem (as a first step) but they should be treated as a key/value store to allow future implementations to move these files to object storage.
• These commands should be allowed to Any, but limiting to their own commands, meaning that if the command they want to check is not theirs it should be a not allowed violation, unless the requester is an admin.

Just run coverage, and we are missing testing this one in builtins.

It would be nice to be able to disable handshakes globally. That is, the ack message that meeseeks writes back when successfully accepting a command.
At the time of this writing, you can only disable the handshake for each command but not globally.

A nice UI could be this, if possible:

format:
  reply_styles:
    handshake: disabled

Replace disabled with false, off, no or whatever you deem more apt.

In some cases this makes sense:

• Make the bot appear as not connected
• Only attend users that have some form of permission, this can be obtained through the groups. Any other user will be flatly ignored.

We're currently lacking a test to ensure an alias does what it says on the tin.

We need to fill the temp db with some operations, create an alias that does something and then run it ensuring that the return value is as expected.

In some cases I would like to have some commands with high security. A way of doing this could be using interactions (that are a bit hard to setup in slack) or to simply use OTP tokens.

For this, we should do roughly the following:

• Wait until we have some form of persistence.
• Wait until we have internal commands.
• Add a command to generate an OTP token that will be communicated to the user via IM messaging, maybe a command like secure <username> issued by an admin would generate a new OTP token.
• When a command gets issued and has a confirmation step:
  • we will store the command data in a confirmation pending bucket with all the arguments, original requester, etc.
  • A meeseek will reply to the issuing channel that command <ID> needs confirmation, issue the command "confirm <ID> <OTP>" via IM to start execution
• When the meeseek gets a confirmation, the command will start with the confirmation granted, and cleanup the confirmation requirement.

Maybe use https://github.com/pquerna/otp for this.

In #94 we've introduced the ability to disable handshake replies. If possible, we should add a test for it.

When thinking about securing the remote execution some thoughts are:

• Unique Remote ID Tagging
  Remote Meeseeks are identified by a unique UUID that must match the established UUID in the Meeseeks "master" configuration. This is needed for a Remote Meesseeks to register with the Master Meeseeks.

• Cert Based Authentication of Command
  When registering a Remote Meeseeks with the Master Meeseeks this should take place over a TLS API call session with a registration endpoint, to start the registration the UUID must match the UUID that has been configured in the Meeseeks Master. Upon a match of UUID for registration the Master Meeseeks should generate a cert for the Remote Meeseeks that is signed by the Master Meeseeks. Once this is established the Remote Meeseeks will not execute jobs unless they have been signed by the Master Meeseeks.

• Time Based Validation (to prevent replay attacks)
  In the metadata of the command submission the Master Meeseeks should submit a timestamp that is generated at command invocation time. The Remote Meeseeks should check the timestamp against its system time and refuse the execution of the command if the skew is greater than an acceptable threshold. This threshold should have a default time of 60s

If it's empty, any channel, else, the meeseeks should reject the command in the channel that is not allowed explicitly.

Currently megacheck throws out a warning:

$ make megacheck
megacheck
main.go:221:2: expected statement, found 'range' (and 1 more errors)

In agent mode, the meeseeks should ship job logs remotely instead of logging to stdout.

We could add a log writer to the the command execution context to allow sending log remotely.

I would start with something simple:

• allow sending a global token through an argument, something like -grpc-token.
• on the server, using grpc-echosystem/auth, add a function that checks that the received token is the one that we accepted as an argument
• on the client, use the same argument to send the token to the server so it checks up.

WDYT @omame ?