August 25, 20230 mins read
Many organizations find it challenging to locate and fix the vulnerabilities in their containers. But the team at Okta knew that securing the containers that support Auth0 (their identity and access (management platform), was imperative. The team also knew these security processes had to be developer-friendly: making finding and fixing container vulnerabilities as simple as possible.
Jim Armstrong, Senior Director of Product Marketing at Snyk, and Zaher Jarjoura, Staff Cloud Security Engineer at Okta, discussed Okta’s process of implementing container security at Snyk’s AWS re:Inforce 2023 session.
Read on for a recap of their discussion, including:
What is Auth0, and what does its architecture look like?
How is Okta working to simplify complexity for Auth0 developers — including security complexities?
What does the Auth0 team’s developer and container security look like today?
What are Okta’s plans for simplifying Auth0’s container security?
Auth0 is a SaaS platform that enables customers to manage their identity and access management (IAM) initiatives from a single pane of glass. Customers can deploy Auth0 as a standard, multi-tenant environment on a public cloud or as a private cloud deployment.
Users often lean towards the private cloud option because it offers more cloud and region choices, better privacy options, more robust performance, and an isolated infrastructure tailored to their use cases.
Okta’s goal to reduce development complexity
This level of private cloud functionality required Okta to set up the correct architecture behind the scenes which prompted them to containerize all Auth0 app components. The Okta team realized that this robust platform would become complex for their developers, so they prioritized reducing this complexity on the backend. For instance, they created a control plane that automatically handles Docker files, Kubernetes orchestration, YAML config, Terraform configuration, and other deployment details.
As they worked on making the architecture run smoothly for developers, Okta knew that they also needed to implement security that would work with — not against — this well-oiled automation machine. But their existing security processes weren’t keeping up with all their other infrastructure automation.
Zaher Jarjoura said, “a lot of the work had been manual and fell on the security team. We would go through the scan results to figure out if the container's still running in production. We'd assess the vulnerabilities and figure out how severe they were. And if the vulnerabilities were critical or high, and the container was still running in production, we'd cut tickets for developers to fix it. It still took a lot of manual research and effort for the developers and, of course, us as the security team.”
Not only did this manual work slow down development, but it also made it challenging to create security reports. At Snyk’s AWS re:Inforce 2023 session, Zaher described it as “manual spreadsheets and screenshots. It took a lot of time that was better spent on more important things.”
The current state of Auth0’s container security
To match Auth0’s container security to the speed of their development process, the Okta team decided to work with Snyk. Okta uses Snyk’s developer-first tooling to scan their images, surface vulnerabilities, compile results into a centralized asset management system, then enrich each scan result with meta-data (locations of running images, image source URLs, etc.)
Zaher sees image enrichment as a vital piece of the puzzle because “it makes it easy to have a view of all of our images, any vulnerabilities they might have, what environments might be affected, and who the owners are. And then, tickets are open for the vulnerabilities, using the owners of the image’s GitHub repo to find the right assignee. And then the responsible team will patch any of the vulnerabilities that are assigned to them.”
This process keeps the release manifest up-to-date with all vulnerability fixes without adding extra tasks to the developers’ plates.
The future of Auth0’s container security
The Okta team will continue to mature its approach to container security over the next few years, aiming to reach two big goals: shifting left and implementing more automation.
Shifting container security left
Okta aims to shift container security left with more guardrails such as custom base image recommendations. These automated guidelines would prevent vulnerable images from entering the development pipeline in the first place. They would also enable the platform security team to curate a collection of “preferred” base images that the development team can easily access and use.
As Jim Armstrong mentioned at the Snyk AWS re:Inforce 2023 session, “With this model, essentially, the app team gets a report that says, ‘well, as long as you're on the most recent version of the internal base image, you're doing okay. If you're not, we'll give you a fix PR to get you to that most recent internal base image.’"
Implementing more automation
In addition, the Okta team hopes to implement more automation, such as automated patch remediation across several iterations of the same image. Because the team already maintains a set of golden base images, many of their running images have common layers. It would save them time to remediate all occurrences of the same vulnerability at once rather than fixing them individually.
Okta also aims to implement PR fix automation, enabling developers to review an automatically-created PR, test the changes, and merge rather than fix it manually.
Snyk’s developer security platform — for containers and beyond
Snyk helps organizations like Okta secure their development processes with a centralized platform that goes beyond container security. Our Snyk Insights capability empowers developers to find and fix security issues in their code, open source, containers, and IaC — all from a single platform.
Watch the full talk to learn more: