Getting Started with YugabyteDB’s Security Features
In this blog post we are going to give you a quick overview of YugabyteDB’s security features . We’ll cover authentication, authorization, encryption, plus a simple security checklist to help lock down your install. For the purposes of this walk-through, we are going to use the Cassandra-compatible, flexible-schema YCQL API as an example.
First things first, authentication is not enabled by default. So, once you are through experimenting with YugabyteDB on your laptop and are ready to start development in earnest, it is highly recommended that you enable authentication. In this section we’ll walk you through appropriate steps to enable and setup authentication in YugabyteDB.
What’s the difference between authentication and authorization? Authentication verifies the identity of a user, while authorization determines the verified user’s access privileges to the database.
YCQL authentication is based on roles. Roles can be created with superuser, non-superuser and login privileges. New roles can be created, and existing ones altered or dropped by administrators using YCQL commands. With YCQL, when you enable authentication it automatically enables the role-based access control (RBAC) feature as well.
Assuming you have started the
yb-tserver process with the
--use_cassandra_authentication=true flag, the following command will enable the authentication features:
./bin/yb-tserver \ --tserver_master_addrs \ --fs_data_dirs \ --use_cassandra_authentication=true \ >& /home/centos/disk1/yb-tserver.out &
By default, a YugabyteDB cluster has an admin user with “cassandra” as both the username and password. This admin user has the
superuser privilege, so it is important to change the password as an immediate first step.
You can connect to the cluster as “cassandra” using the following command:
$ cqlsh -u cassandra -p cassandra
Next, let’s change the password for the admin user.
cassandra@cqlsh> ALTER ROLE cassandra WITH PASSWORD = 'new_password';
Check out the authentication documentation page to learn how to:
- Create new users, including superusers
- Edit user accounts and manage passwords, grant and revoke privileges
- Delete users
As mentioned, authorization is about what sort of activities a user is allowed to perform. With YugabyteDB, roles determine what a user can and cannot do. The role-based access control model in YCQL is a collection of permissions on resources given to roles. Thus, the entire RBAC model is built around roles, resources and permissions.
- Roles represent individual users or a group of users.
- Roles can be granted to other roles, making it possible to organize them into hierarchies
- Roles inherit the permissions of all other roles granted to them
YCQL defines a number of specific resources, that represent underlying database objects. A resource can denote one object or a collection of objects. For example: keyspaces and tables follow the hierarchy: ALL KEYSPACES > KEYSPACE > TABLE ROLES.
Permissions are required for a user to perform operations on database objects. Operations can include things like
SELECT. Permissions can be granted at any level of the database hierarchy and are inherited downwards.
Check out the authorization documentation page to learn how to:
- Create, grant, list, revoke and drop roles
- Create a hierarchy of roles
- Create, grant, list and revoke permissions
- Internal communication between YugabyteDB nodes
- Communication between applications and YugabyteDB
- Communication between command line shell and YugabyteDB
Stay tuned for a blog post next week with detailed information on how encryption works and how to configure it.
As with any database installation you are going to want to do a basic “lock-down” of the system before beginning development. Here’s a basic checklist every developer should work through to secure YugabyteDB prior to moving to production.
- Enable authentication
- Configure RBAC
- Run as a dedicated user
- Restrict machine and port access
- Limit the interfaces YugabyteDB uses to listen for incoming connections
- Assign YugabyteDB private IPs vs public ones.
- On AWS, run YugabyteDB in a separate VPC if possible and peer it only with other VPCs where databases access is explicitly required.
- Make the security groups assigned to YugabyteDB very restrictive by ensuring that they can only communicate with each other on the necessary ports and expose only the client accessible ports to the servers.