KeyConf NYC Interviews – Managing Human and Machine Identities

David Spark: Gavin, alright put yourself, your brain, just prior to COVID. What was secure remote access to you prior to COVID with your customers and your DevOps team? What was it? Just describe that world. Don’t describe what happened after that. I know something changed. Describe that world to me.

Gavin Grisamore: Right. Well, just for our employees at Stash, we’re located in an office in Manhattan and we had all of our technology set up there. We’re cloud native. We connect to the cloud. We have things set up for that, but we’re primarily an office-based company.

DS: So, people didn’t connect remotely or they did?

GG: We had a VPN solution in place but we had things like IP whitelisting and some other stuff with our office and some hosted things within our office to handle and or eliminate.

DS: It sounds like it maybe it was a very manual, very cloogy to do remote access at the time.

GG: Yeah, it was really only used for the rarity when employees work from home which just didn’t happen.

DS: And it was a rarity at that time. Okay. COVID hits, what happens?

GG: You have a lot of, the business needs to keep moving. So, you have a lot of operators that need to keep building and developing in the cloud. They need to connect to those resources and we had a VPN solution, but the capacity just wasn’t there. So, that was sort of your first problem and now you’re taking IT teams and devoting to a capacity problem, but you’re forgetting all the security risk. Again, the business needs to continue moving forward.

So, we have a pipe essentially VPN to our cloud services, but we don’t have granular access control set up. We don’t have the ability to segment your viewing to certain applications and VPNs are notoriously clunky. They add overhead to your requests. They’re not really beloved by the employees at the organization. So, you have lots of compounding problems.

DS: Okay. So, you’re like, we need a better solution. Yes, can I assume any we need a better solution right now?

GG: Yes. We need it immediately. Yes.

DS: So, what started to change.

GG: So, we started to look at Zero Trust network access solutions. The advantage of our company is we’re small and we’re already cloud native and we don’t have to operate our own data centers. We have a lot less complexity.

DS: So, your shift wasn’t as tough as somebody else’s.

GG: Definitely not.

DS: Okay.

GG: We needed to primarily focus on AWS and that cloud environment and how do we get our operators and developers connecting to that environment. So, we looked at several different solutions. We ended up going with a Akeyless and another Zero Trust network Access Broker and we’re kind of using them in tandem with each other. Akeyless is more for privileged access management and the secrets management and getting access to that. It’s also a backup to the network component.

We have a lot of internal APIs that need to be connected to and that’s also a challenge for application-based solutions like Akeyless. So, you still kind of have to have that network component there.

DS: I’m assuming you looked at competitors, yes?

GG: We did, yes.

DS: Why did you land on Akeyless?

GG: Akeyless offered the balance of not only do we have to solve the secure remote access component; we have to solve secrets management. That is a problem that we also were dealing with and we like the ability to have that in one solution. You can manage all of your identities both human and machine in one place for a small security team and a small staff that’s easier to use. Also, it’s easier for our developers to understand. They sort of see one solution and that solution is sort of Akeyless.

That’s how they connect. That’s how they’re going to input their secrets and it’s kind of a lather rinse repeat. No matter what you’re doing whether it’s privileged access management or secrets management etcetera. You’re going to be using Akeyless for the particular solution. So, that was what was attractive about it.

DS: What’s the feedback from your users since you moved over to Akeyless.

GG: Definitely a lot of simplification. We were using products before like AWS’s Secrets Manager and we felt that that was good enough for storing a particular credential or secret, but you don’t really get the full life cycle around it. It’s not going to help you integrate with your CI/CD pipeline. It’s not going to automatically and dynamically rotate some credentials for you unless you’re using RDS, a very specific AWS technologies. And you’re limited to only the cloud offering of AWS.

We have some future plans of expanding to leverage other clouds as well. So, it’s another hat in sort of Akeyless is ring as it’s cloud agnostic.

DS: Good point. Now, how forward thinking are you on this? Like, what would you like to be dealing with secure remote access that would make your life even easier?

GG: That’s a good question. I think rolling it out has been fairly simple. Where you get into trouble is the configuration on what you want individuals or individual teams to have access to and to limit that as much as possible. Sometimes that is rather difficult to practically do. You can segment it by, okay these development teams have five applications and maybe you only allow them to access those five applications. But in reality, there’s other supporting applications that need. How do you only allow access to exactly when they need it? So, combining something like connections to a ticketing system or the ability to dynamically request something, do an approval, grant access, and then allow that access and then maybe that access is terminated after a period of time.

So, you can start to have a process for it. It’s well managed and then that access goes away. It doesn’t live on forever and you start to really build on that life cycle.

DS: Awesome. Well, thank you so much for your time. I appreciate it.

GG: Thanks for having me.