Pino de Candia
Change-Id: I4f0e14f41072f87d83d8b3d31af4e2e9026c9892 Signed-off-by: Pino de Candia <firstname.lastname@example.org>
|3 years ago|
|alembic||3 years ago|
|devstack||3 years ago|
|doc/source||3 years ago|
|etc||3 years ago|
|files||3 years ago|
|releasenotes||3 years ago|
|scripts||3 years ago|
|tatu||3 years ago|
|.gitignore||3 years ago|
|CONTRIBUTING.rst||3 years ago|
|HACKING.rst||3 years ago|
|INSTALLATION.rst||3 years ago|
|LICENSE||3 years ago|
|README.rst||3 years ago|
|TRY_IT.rst||3 years ago|
|alembic.ini||3 years ago|
|babel.cfg||3 years ago|
|pylintrc||3 years ago|
|requirements.txt||3 years ago|
|setup.cfg||3 years ago|
|setup.py||3 years ago|
|test-requirements.txt||3 years ago|
|tox.ini||3 years ago|
Named in honor of Tatu Ylönen, the inventor of SSH, Tatu is an OpenStack service that manages user and host SSH certificates. Tatu can also start and manage bastion servers so that you don't have to (and so you don't have to give every SSH server a public IP address).
Tatu uses Barbican to store two private keys per OpenStack project:
Tatu provides APIs that allow:
During VM provisioning:
During negotiation of the SSH connection:
Use of host certificates prevents MITM (man in the middle) attacks. Without host certificates, users of SSH client software are presented with a message like this one when they first connect to an SSH server:
The authenticity of host '126.96.36.199 (188.8.131.52)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)?
There's no way to verify the fingerprint unless there's some other way of logging into the VM (e.g. novnc with password - whhich is not recommended).
It should be obvious that using certificates SSH servers only need to store the user CA public key (and a digest of revoked client certificates), not every client certificate. This is simpler, more secure and more manageable than today's common practice: putting each user's public key in the SSH server's authorized_keys file.
Please see the INSTALLATION document in this repository. Then see the TRY_IT document for step by step instructions on using it.
Tatu provides REST APIs, Horizon Panels and OpenStack CLIs to:
Tatu does not currently generate SSH keys for VMs (although we may consider this feature later since Barbican may be able to generate better quality keys).
On first boot, the VM calls Tatu's /hostcerts API to request a host certificate. It passes as parameters the SSH public key (currently the RSA key) and a one-time-token. The one-time token was previously generated by Tatu on a request by Nova for dynamic vendor data, and then passed to the VM via ConfigDrive.
The VM also periodically (every 60 seconds) calls Tatu's /revokeduserkeys API to refresh its local revoked-keys file (configured via RevokedKeys in sshd_config).
The VM's access to the Tatu API must currently go over http (not https) and cannot be authenticated via Keystone. We aim to improve this in the future. We therefore expose the /hostcerts and /revokeduserkeys APIs without authentication (with a /noauth path prefix). The one-time-token prevents malicious users from generating host certificates. The /hosttokens API to generate one-time-tokens is only accessible with Keystone authentication, can be secured with TLS, and is only meant to be called by Nova's dynamic vendor data mechanism.
In order to further secure Tatu's /noauth path, we intend to have VMs access Tatu's API via the Metadata Proxy. We have an experimental implementation with the Dragonflow Neutron plugin. In this case the VMs access the API at 169.254.169.254:80 and the Metadata Proxy distinguishes Tatu calls from Nova metadata calls and proxies them to Tatu instead of Nova. In support of this feature, Tatu's configuration has an api_endpoint_for_vms parameter in support of this feature. The VM learns what IP address to use via Tatu's dynamic vendor data.
User certificates are generated with a per-project User CA. Host certificates are generated with a per-project Host CA.
An OpenStack user wishing to ssh into VMs belonging to different projects will require one certificate per project.
In the future we will consider using per-domain User and Host CAs.
When a user SSH certificate is created for a given project, the list of principals is equal to the user's role assignments in Keystone. If any of the user's role assignments are deleted, Tatu automatically revokes any of the user's certificates whose principal lists contain that role name.
When a Linux VM is launched, Tatu sets up a user account for each of the roles in the project at that time. As of March 2018, there is no support for sync-ing the Linux user accounts in the VM with the project's roles if they change after VM launch.
Tatu leaves root and non-root default users (e.g. fedora use on fedora VMs) intact, including any authorized_keys files. As a result, OpenStack KeyPairs continue to work as designed, which is useful for debugging Tatu or having a fallback method to access the VMs.
Tatu's policy is that any role containing the word "admin" results in a user account with sudo privileges. Note that because of this policy, an OpenStack user may not have sudo privileges on VMs she herself launched.
Thanks to the uber/pam-ussh integration sudo privilege is revoked as soon as the VM learns that the user's certificate has been revoked. However, uber/pam-ussh requires the client to run ssh-agent, ssh-add their key (corresponding to their certificate) and launch ssh with the -A option.
This feature is enabled/disabled by setting pam_sudo to True/False in tatu's configuration. When the feature is disabled, sudo access is not authenticated, it's password-less (since we don't use passwords in our user account setup).
Tatu aims to manage SSH bastions for OpenStack environments. This feature would provide the following benefits:
As of March 2018, Tatu does not yet support general bastion management.
However, Tatu has an experimental feature (off by default) to provide ssh access to VMs via PAT (port address translation). PAT provides only some of the previously mentioned benefits of bastions: it avoids assigning a FloatingIP per VM, but it does not provide a single point of policy enforcement because PAT always translates and forwards without checking certificates as a full SSH proxy would. PAT bastions are only supported by an experimental version of Dragonflow Neutron plugin. It works as follows:
Automated user key rotation is not required because the API already allows generating new user certificates on demand.
Is automated server key rotation useful? Would yearly Host CA key rotation make server key rotation redundant?