Security

Quite deliberately, freckles will never require any sudo/root permissions when installed or run by itself. It will only ask you for a sudo password when you tell it to run tasks that require them. So, there will never a need to do something like:

sudo freckles ...

freckles has internal smarts to figure out whether it needs to ask for a 'sudo' password, here's how that goes:

• check if the frecklet needs elevated permissions at all
  • if no elevated permissions are needed, don't do any further checks
• check if the '--ask-become-pass' flag is set
  • if it is, ask for the password and use that in the run
• check if the target user is 'root'
  • if it is, nothing further will be done
• check if the target is local or remote
  • if remote:
    • assume the login user will have password-less sudo access (or is 'root', in which case the question is moot)
  • if local:
    • check the username in the 'target' variable
      • if the user in the target variable is the same as the one running freckles
        • check if the current user can do 'password-less sudo'
          • if it can, do no further check and use that to get elevated privileges whenever necessary
        • if it can't do password-less sudo, ask for the users password and use that down the line (if the user does not have sudo permissions at all, the run will fail eventually)
      • if the user in the target var is different than the one running freckles
        • use/change 'ssh' as connection type instead of 'local' (if no ssh server is running, this will fail)
        • assume the login user will have password-less sudo access (or is 'root', in which case the question is moot)

So, what this means in practice is that if you have a task that requires elevated permissions, and the task runs locally as the same user that runs freckles ('-t localhost', or no '-t' flat at all), , freckles will do the right thing, and will only ask for a password if necessary.

If you run a task with a remote target, you have to specify the '--ask-become-pass' flag in the cases where the remote user (the 'user' part in '-t [email protected]') can't do password-less sudo (but has sudo permissions in general -- if it has not, the task will fail at some point).

The bootstrap script

Binary signing

As was mentioned above, freckles only asks you for sudo/root passwords when the task you are about to run requires it. Sometimes freckles itself will be run as the root user, for example when run inside a Docker build process. Sometimes, as is the normal case, a system is setup so that there exists an admin user who has access to sudo without having to provide a password. In fact, freckles comes with a frecklet to setup just that.

In any way, be extra diligent when root permissions are required (which is basically 90% of the time, unfortunately).

'Trusted' frecklets

Remote repo permission config

Some frecklets need passwords as user input. This is a difficult thing to do securely. freckles still misses a few features that will make handling passwords better, easier, and more secure. In the future there will be integration to password stores (e.g. Hashicorp Vault, Bitwarden, the OS keychain, ...). For now, there are only a few basic options, so it's a good idea you know about them, so you can choose the best one for your scenario.

When writing a frecklet, you can mark arguments secret, which will tell freckles to handle them differently to 'normal' ones. It looks like this:

args:
  db_password:
    doc: The password for the database.
    type: string
    required: true
    secret: true
  other_arg:
    doc: ...

All the frecklets in the 'default' and 'community' repositories use this marker. If you use a frecklet from a 3rd party, have a look at it's content and make sure this is done properly. This is probably also a good indicator on the quality of the frecklet in question...

Plain password via cli arg

frecklecute user-exists --password password123 markus

Using the '--vars' arg

Using the '::ask::' var adapter

frecklecute user-exists --password ::ask:: markus

Input needed for value 'password': the user password in plain text
  password:

Using an Ansible lookup plugin

frecklecute user-exists --password "{{ lookup('<lookup_plugin_name>', '<lookup_plugin_arg>' }}" markus

frecklecute user-exists --password "{{ lookup('file', '/tmp/password' }}" markus

frecklecute user-exists --password "{{ lookup('env', 'MY_PASSWORD' }}" markus

frecklecute user-exists --password "{{ lookup('keyring', 'my_user_passwords markus') }}" markus

This is a topic you can do nothing about, but I think you should know how freckles internally handles passwords. Most importantly, to be able to make an informed decision on whether you want to trust freckles with your passwords at all.

This behaviour is highly adapter dependent. As the nsbl adapter is the only functional one at the moment, I'll only describe that one here:

• you enter the password in one of the ways described above
• freckles keeps it in memory, and eventually hands it off to the adapter that runs the frecklet in question
• the 'nsbl' adapter takes the var_name/password map and replaces the password with a string like: {{ __secret_<variable_name>__ }}
• it creates an Ansible vault file, using a randomly generated key and puts it into the playbook directory (using this bash script)
• a vault key file (with only read permissions for the current users) with the random password is written in the Ansible playbook directory
• the ansible-playbook run is kicked off using --vault-id=freckles_run@<vault_key_file> --extra-vars=@$<vault_file>
• as a first thing done in the Ansible run after reading them, the key file is being deleted
• after the run finishes, freckles tries in two more places to delete those two files, in case there was an error and Ansible could not delete the files itself

This is still not 100% ideal, as there is a chance that when the freckles run is interrupted at just the right place, the files might not have been deleted and local users who have access to your user account could read them. I do think this is an acceptable trade-off, because, chances are, that if that's the case you have bigger things to worry about anyway. But that decision is up to you.

Last, but not least, freckles is written in Python, which does not allow to overwrite strings in memory to 'destroy' passwords once they are no longer needed (as far as I know -- do let me know if I'm wrong!!!). So this is a limitation we'll all have to live with, unfortunately.

Currently, there is only very basic support for returning results from tasks. Often results are not necessary, because all the information necessary is in the input variables of a task. In some cases it is important though, for example when creating a virtual machine in the cloud, and you need to know the public IP address for the machine to be able to connect to it. This can be done with freckles, but in some cases the information sent back contains secret information (like for example a root password if no ssh-key was specified when creating the server). For now, freckles does nothing to hide those secrets, and it is the users responsibility to either make sure those secrets aren't sent in the first place (in our example by providing a ssh key when creating the server), or by other means (changing the password instantly etc.).

Is there anything I forgot? Anything you would like to know, or point out? If you have any concern, or any idea how to make any of this more secure, please let me know!

I take this topic seriously, and I try to be as open and informed as my feeble mind and my time allow me to be. But I'm fully aware that there is quite a bit I don't know, so please give me as much feedback as you have. Every little bit helps!