Otterize launches open-source, declarative PostgreSQL permissions for RDS workloads on AWS EKS clusters

Anyone who’s had to administer a database will be able to tell you that managing access to databases and tables is a constant battle between allowing enough access and allowing too much access. How do you make sure that the apps that need access to read from the database – and certain tables within the database – have the proper grants? How do you ensure that you’re not just giving everyone a default set of grant options that may be far too unrestricted?

These are, of course, also security concerns. If you’re not careful, you can end up with a situation where a developer has access to a production database and can read and write to tables that they shouldn’t be able to. This is a problem that’s been solved in the past by creating a separate database for each developer, but that’s not always practical.

Once you bring Kubernetes into the mix, things get exponentially more difficult to manage. You have to make sure that the pods that are running in your cluster have access to the database, but you also have to make sure that they don’t have too much access. And you have to share the database secrets among pods so that they can connect to the database, but you have to make sure that the secrets are properly secured.

No more! The open-source intents-operator and credentials-operator enable you to achieve the same, except without all that work: do it all from Kubernetes, declaratively, and just-in-time, through the magic of IBAC (intent-based access control).

How does it work?

Step 1: Annotate a pod, requesting a user and a password to be provisioned and bound to the pod.

Annotate the pod with this annotation:

"credentials-operator.otterize.com/user-password-secret-name": "booking-service-user-password"

Otterize then provisions credentials for this specific workload in this namespace in this cluster, that is not shared with other workloads.

Step 2: Declare your workload’s ClientIntents, specifying desired permissions.

apiVersion: k8s.otterize.com/v1alpha3
kind: ClientIntents
metadata:
  name: booking-service
  namespace: flight-search
spec:
  service:
    name: booking-service
  calls:
    - name: flight-search-db
      type: database
      databaseResources:
        - table: flights
          operations:
            - SELECT
        - table: bookings
          operations:
            - ALL

Otterize then creates a user and matching grants on the target database.

Step 3: Done! Your workload can access the PostgreSQL database. The database, users, and grants will be kept in sync with the cluster state, as you update your Pods and ClientIntents.

Conclusion

That was a lot easier than anything I had tried to do with the PostgreSQL and AWS so far. I was able to create a new user, grant it permissions, and then use those permissions to query the database. And I was able to do it all declaratively, which means that I can now check this into source control and have a repeatable process for creating and managing permissions.

Wondering what are ClientIntents? Read more about IBAC, intents-based access control.

Can I also map SQL calls?

Coming soon: capture SQL calls for pods in your cluster, automatically generating the required least-privilege permissions, or ClientIntents, for each workload. Zero-friction in development, zero-trust in production. It’s coming.

If you want to learn more, and meet other Otterize users, please Join our Community and chat with us!