2 posts tagged with "security"

Hi everyone,

Thanks for joining us today for our v0.25 release announcement! In this version we are introducing a new feature that has been requested by many of you: support for Row-level Security Policies in PostgreSQL.

Additionally, we have made some minor changes to our pricing plans, more on that below.

What are Row-level Security Policies?​

Row-level security (RLS) in PostgreSQL allows tables to have policies that restrict which rows can be accessed or modified based on the user's role, enhancing the SQL-standard privilege system available through GRANT.

When enabled, all normal access to the table must comply with these policies, defaulting to a deny-all approach if no policies are set, ensuring that no rows are visible or modifiable. Policies can be specific to commands, roles, or both, providing fine-grained control over data access and modification.

How does RLS work?​

When you create and enable a row-level security (RLS) policy in PostgreSQL, the database enforces the specified access control rules on a per-row basis.

For example, you can create a policy that allows only employees to see their own records in an employees table. The policy could look like this:

CREATE POLICY employee_policy ON employees
  FOR SELECT
  USING (current_user = employee_role);

This SQL command creates an RLS policy named employee_policy on the employees table. The FOR SELECT clause specifies that this policy applies to SELECT queries. The USING clause contains the condition current_user = employee_role, which means that a user can only select rows where the employee_role column matches their PostgreSQL username.

Next, database administrators typically run:

ALTER TABLE employees ENABLE ROW LEVEL SECURITY;

This command enables RLS on the employees table. With RLS enabled, PostgreSQL will check the policies defined for this table whenever a user attempts to access or modify existing rows, or insert new ones.

When a user executes a SELECT query on the employees table, PostgreSQL evaluates the employee_policy. If the user's PostgreSQL role (username) matches the employee_role column value in a row, the row is included in the query result. Otherwise, the row is excluded.

For instance, if the employees table contains the following data:

When the user alice runs SELECT * FROM employees, PostgreSQL applies the policy:

SELECT * FROM employees WHERE current_user = employee_role;

This results in:

By enforcing these policies, RLS ensures that users only have access to the data they are permitted to see, enhancing the security and privacy of the database.

Manage your Row-level Security Policies as Code​

With Atlas, you can now manage your RLS policies as code, just like you manage other database resources such as tables, indexes, and triggers. This allows you to version control your policies, track changes, and apply them consistently across your environments.

To get started with RLS in Atlas, first upgrade to the most recent version.

curl -sSf https://atlasgo.sh | sh

brew install ariga/tap/atlas

docker pull arigaio/atlas
docker run --rm arigaio/atlas --help

docker run --rm --net=host \
  -v $(pwd)/migrations:/migrations \
  arigaio/atlas migrate apply
  --url "mysql://root:pass@:3306/test"

RLS is available to Atlas Pro users only. Get your free Atlas Pro account today by running:

atlas login

Next, you can define your RLS policies in your Atlas schema file (schema.hcl) using the new policy block:

policy "employee_policy" {
  on    = table.employees
  for   = SELECT
  to    = [PUBLIC]
  using = "(current_user = employee_role)"
}

This HCL snippet defines an RLS policy named employee_policy on the employees table, allowing only users whose employee_role matches their PostgreSQL username to SELECT rows from the table.

Next, you need to enable RLS on the table:

table "employees" {
  schema = schema.public
  column "employee_role" {
    type = text
  }
  row_security {
    enabled  = true // ENABLE ROW LEVEL SECURITY
  }
}

Finally, run atlas schema apply to apply the changes to your database!

To learn more about RLS using Atlas, check out our documentation.

Introducing Atlas Pro​

Since launching Atlas Cloud a little over a year ago, we have been working hard with our users and customers to make Atlas as easy and simple to use as possible.

One point of confusion we have encountered, especially around our pricing plans, was how users who currently don't want (or can't) use Atlas Cloud for their CI/CD pipelines can get access to the advanced CLI features that Atlas offers. Previously, teams needed to buy Cloud quota to get access to the CLI, which didn't make a lot of sense.

To address some of these issues we are making some small changes to our pricing plans:

Atlas now comes in three tiers:

• Open - Our CLI, doesn't require creating an account and comes with a solid set of features (this is more than enough for many of our users).
• Pro (previously "Business") - An enhanced version of our CLI, which includes support for advanced database features and drivers. It will cost $9/month/user, but users get their first 3 seats per company for free when they sign up. Pro users also have access to Atlas Cloud (pricing remains the same).
• Enterprise - our enterprise tier, targeted mostly at larger organizations or teams in regulated industries with stricter compliance requirements.

To learn more about our new plans, head over to our updated pricing page.

Wrapping Up​

That's all for this release! We hope you try out (and enjoy) all of these new features and find them useful. As always, we would love to hear your feedback and suggestions on our Discord server.

Today we are happy to announce that Atlas Cloud, our cloud offering, has achieved SOC2 compliance. This is a big milestone for us, which shows our determination to providing solid infrastructure for our users and customers.

SOC2 is a security and compliance standard that helps organizations demonstrate their ability to protect customer data and ensure the availability of their services. It’s like an independent third-party audit that evaluates how well a company follows industry-standard security practices, covering areas such as availability, processing integrity, confidentiality, and privacy.

Achieving SOC2 compliance requires a significant investment in time, effort, and resources, so you may be wondering why we decided to pursue this goal so early in the life of our product. The knee-jerk response of any seasoned engineer to large and long infrastructure projects should is:

YAGNI. You ain’t gonna need it.

When building software systems, we often spend a huge amount of time developing abstractions and tooling, only to find out that product requirements changed, rendering our work useless.

The first commandment of the lean movement: Waste Not. Do the minimum you can to learn what will work. Do less to move fast. But there’s another side to this coin: teams with solid infrastructure move way faster. Try driving a sportscar on a shabby dirt road.

*So why invest resources in compliance early on?

First of all, are we gonna need it? What are the odds that we won’t need the SOC2 certification, and that it won’t bring us business value?

Ariga is an open-core company building tools for software engineering teams. We are building Atlas Cloud to be the safest, fastest, and richest way for organizations to manage database schema changes.

We believe that in order to earn the trust of other organizations, in order for them to grant us the privilege of being infrastructure to their business, we must hold ourselves accountable to rigid standards.

To be perfectly honest, the vast majority of the things that we were required to demonstrate in the compliance process, such as mandatory code reviews, disaster recovery, and data privacy controls are things that we consider just consider to be solid engineering practices that we hold ourselves accountable to regardless of an external auditing process.

We are proud of this accomplishment and look forward to continuing to provide our users with the best possible experience using Atlas Cloud. We will continue to invest in our security and compliance programs to ensure we stay ahead of the curve and remain a trusted partner to our customers.