Getting Started with YugaByte DB’s Security Features
In this blog post we are going to give you a quick overview of YugaByte DB’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 YugaByte DB 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 YugaByte DB.
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.
1. Enable authentication
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:
>& /home/centos/disk1/yb-tserver.out &
2. Connect as admin
By default, a YugaByte DB 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
3. Change the admin password
Next, let’s change the password for the admin user.
cassandra@cqlsh> ALTER ROLE cassandra WITH PASSWORD = 'new_password';
More on authentication in YugaByte DB
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
Authorization with RBAC
As mentioned, authorization is about what sort of activities a user is allowed to perform. With YugaByte DB, 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.
More about authorization in YugaByte DB
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 YugaByte DB nodes
- Communication between applications and YugaByte DB
- Communication between command line shell and YugaByte DB
More about encryption in YugaByte DB
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 YugaByte DB prior to moving to production.
- Enable authentication
- Configure RBAC
- Run as a dedicated user
- Restrict machine and port access
- Limit the interfaces YugaByte DB uses to listen for incoming connections
Tips for Public Clouds
- Assign YugaByte DB private IPs vs public ones.
- On AWS, run YugaByte DB 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 YugaByte DB 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.