About Divvy
Divvy is a financial technology company that offers a rent-to-own program, allowing renters to build equity in a home with the option to buy it within a few years.
“We use P0 to control privileged access for GCP and Snowflake, including production databases such as CloudSQL, Kubernetes (GKE) and other services. Developers generally do not like any product or policy that restricts their access to production, but our roll-out of P0 has been very smooth. I hear several engineers comment on how easy P0 makes their day-to-day jobs.
Before switching to P0, our infrastructure team used another popular PAM solution, which was architected as a network proxy. This solution was not easy to use, especially as our organization became more cloud native, and started deploying workloads on Kubernetes.
We switched to P0 last year, and there have been several benefits. Not only do they cover more access use cases than our legacy PAM product, but they also provide visibility into over-privileged access within GCP. They have made our journey to SOC2 much easier”
David Schlesinger, VP of Engineering
Challenge
Divvy, stores and processes sensitive financial data, including SSNs and other financial information of their users. Divvy had implemented strict access controls on databases containing customer data in GCP. Before engaging with P0, Divvy faced several challenges with their IAM set up.
- Operational overhead: The platform team was processing several access escalations via JIRA tickets, or ad-hoc messages over email or Slack. The team wished to reduce this operational overhead, since they wanted to spend their time on revenue-driving features and priorities.
- Hard to deploy: The team had invested in a legacy PAM solution that required deploying a proxy or a bastion before every resource that they wanted to secure. This was especially hard for cloud-native resources. For example, for Snowflake, admins need to follow several steps for every database that requires access control. Given the high usage of Snowflake, this process was very cumbersome.
- No control over cloud entitlements: Over time, as Divvy’s developers began building on cloud-native technologies (such as GKE, Snowflake and other GCP services), they started using the native entitlements in GCP and Snowflake IAM. The proxy could not control these entitlements, which greatly reduced its ROI.
- Developer experience: The legacy PAM was not very easy to use for the development team, especially for a modern cloud-native stack. Given the complexity of the cloud, any attempt to implement fine-grained access led to a poor developer experience, as developers usually didn’t know what group or role to request
Solution
The P0 team worked together with the Divvy infrastructure team to develop and operationalize a migration plan for the legacy PAM solution. They were able to successfully migrate the entire org to P0 in a few days with minimal disruption to developer workflows.
Key Features:
- Control Standing Access: Divvy’s engineering teams use P0 to define standing access for Postgres for their developers.
- Access to GCP resources: Engineers can use P0 for just-in-time access to sensitive resources in GCP, such as Postgres (CloudSQL), GKE and BigQuery.
- Slack integration Engineering team uses P0’s Slack integration for access requests and approvals.
- On-call automation via PagerDuty: Using P0’s integration with PagerDuty, on-call engineers can get automated access without requiring a human approval
Impact
- Developer Experience:some text
- Mean-time-to-resolution of access requests has dropped from hours to minutes.
- For database access, developers use P0’s features to request access for specific SQL queries. This makes it easier to request least-privileged and fine-grained access to exactly what the developers need, without getting lost in the complexity of Snowflake or Postgres IAM roles.
- Security:some text
- P0 has automated many of the infrastructure team’s repetitive tasks, while enhancing the overall security posture.
- P0 also gives the infra team visibility into over-provisioned access and unused keys, which the legacy PAM did not provide.
