🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.
Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!
Overview
📖 AWS re:Invent 2025 - Zero-Touch Secret Rotation, now available for your third-party secrets (SEC230)
In this video, Ritesh Desai from AWS and Raj Parthaje from Fannie Mae discuss AWS Secrets Manager's new managed external secrets capability for third-party secrets like Salesforce API keys. The feature eliminates the need for custom Lambda functions and manual rotation processes, providing native integration with three ISV partners at launch. Fannie Mae, as a pilot customer, shares how this solution addresses pain points including operational complexity, manual processes, and business interruption risks. Key benefits include automated rotation, centralized visibility, multi-region replication, and reduced human access to secrets. A console demo shows the streamlined setup process with predefined metadata formats and automatic rotation immediately after secret creation, maintaining audit trails through CloudTrail while shifting rotation responsibility to AWS.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introducing AWS Secrets Manager's Managed External Secrets Capability
Good afternoon and welcome everyone. Thank you for coming. I know it's the end of Thursday and it's kind of hard, so I appreciate you taking the time and coming to talk with us. Today we will take an opportunity to talk through AWS Secrets Manager's extension of its current capabilities from natively managing and rotating AWS secrets to now doing something very similar for non-AWS secrets or third-party secrets, which has always been a challenge.
My name is Ritesh Desai, as it says, and I'm here joined with Raj Parthaje from Fannie Mae. Raj is going to take an opportunity to talk through Fannie Mae's use case and how this specific delivery of managed external secrets benefits them. By the way, I will have to share that Raj and Fannie Mae have been partners and customers, talking with us over multiple years and providing us with timely and valuable feedback, which has eventually led to a lot of launches enhancing overall customer security posture. So thank you.
All right, so obviously, as is tradition with Amazon, we start with the customer problem, and then I'm going to talk a little bit about how we thought about the approach to the solution and then eventually how we got to what we launched, managed external secrets. Of course, followed up, you don't have to take AWS's word for it. There'll be a customer, Fannie Mae, talking about how this has helped them and continues to benefit them in the future. We will end, I will take on after that and talk a little bit about the high-level workflow, and then do a couple-minute demo and I'll talk through what exactly is happening in that demo.
All right, so customer problem, third-party secrets. There are a bunch of customers that store third-party secrets like, let's call it Salesforce API keys and other such secrets that sometimes it's really hard to set up a regular rotation for this. You have to build Lambda functions, and then each third party has separate Lambda functions. There is an inherent risk of rotation or availability risk. What if it rotates in Secrets Manager but does not rotate at the source, and so there's a downtime risk? There's the continued cost of keeping all of those Lambda functions up to date security-wise and things like that.
So we started to think about the problem in a way that we've thought about AWS secrets. Secrets Manager today integrates with all AWS services that use a customer secret, right, and we natively integrate with them and rotate them. So for example, if a customer creates an RDS instance, they can simply do a checkbox and it will automatically store the secret in Secrets Manager and set it up for rotation. So then we started thinking about it and we said, well, why can't we do that for non-AWS secrets, right? Why can't we? And then after that, after months of working with customers and partners, we eventually came up with a strategy of building this, what we launched, managed external secrets.
So this was launched last week. We are going out today in the spirit of being incremental in nature. We'll have three partners that we are actively integrated with. Of course, Fannie Mae has been the pilot customer, giving us feedback along the way, and we have eventually launched it last week. So this is kind of my time to say, okay, let's talk and learn from Fannie Mae and see what and how their use cases are being solved by this.
Fannie Mae's Experience: Pain Points, Desired Capabilities, and Results
Thank you, Ritesh. My name is Raj Parthaje. I'll be talking about a few things in terms of the customer pain points, what are the outcomes we are looking for out of this particular capability point of view, and by using this solution, what results we are able to achieve.
So with that, let me give you a little overview about Fannie Mae. Fannie Mae is a chartered organization by the US Congress in 1938. Fannie Mae provides a reliable source of affordable mortgage credit to borrowers and renters in the United States.
So with that, let's go over some of the pain points of what we have observed in our environment. So when it comes to the third-party secret manager, by the way, we have been using the AWS Secrets Manager since its inception. We were partnered with AWS to build the services, which is helpful for all of us. How many of you are really facing these pain points of managing the secrets? How many of you are using it? Yeah, it's really...
What are the pain points of managing secrets? If you look into the diagram over there, when you have to manage third-party secrets, you have to write a custom function to manage and rotate that secret. Now you have to schedule that function. You have to do the observability around it. All these things become custom development, so it increases the complexity. Managing and maintaining this custom solution is going to require additional resource capacity. Inefficient manual processes are involved. For example, how are you going to rotate the secret if you are not writing that Lambda function or something to rotate the secret? If you are doing it manually, think about that manual complexity and what risk it's going to bring to your business processes. What's going to happen if your secret rotation fails or it is not timely updated? The risk of interruption to your business is going to be very high if you do the manual processes, and the inappropriate effort that you need to spend on managing these secrets adds overhead. Think about it. It's not just one ISV or one third-party SaaS that you're going to integrate. Most likely in this cloud world, we have to integrate with many of them. So what that means is several custom things you need to manage and maintain. These are all the pain points. Not only that, when there are version changes, you have to change those as well.
So with that, let's look into what are the desired capabilities we are looking for when we observed these particular pain points. We want to enable centralized onboarding and managing of these credentials. Why is it important? By doing so, we should be able to give the self-service capability to our application teams so that they could manage those credentials. We want to ensure that there is a reliable and secure way of getting the secret from AWS Secrets Manager for the application to consume the secret, which capability is already available, so leverage those capabilities. We want to support seamless credential rotation so that we minimize the business interruption as part of this rotation cycle. Another important feature that you need to look into is that the secret needs to be replicated to multi-regions because if your application is running in a multi-region, you don't want the secret to be consumed from one region to another region, so the secret replication is a key desired capability. We also want to provide complete compliance and governance for the secret rotation capabilities. So these are all the desired capabilities that we put forth with the product team, and with these new features when we integrated, the following results are what we have observed.
Operational efficiency. This allows us to streamline the secret onboarding and secret management. At the end of the day, the manual processes that I'm talking about are no longer really required. It may be required to initiate things in some cases, but at the end of the day, the secret is auto-managed. So that goes into automated compliance. You get the inbuilt ability to auto-rotate the secret based on the policies. You just define the policy. What is the good part of this? If you manually onboard the secret, the person who onboards the secret still has the knowledge of the secret. There is a risk associated with that knowledge, right? You don't want people to have the secret. You want the system to have the secret. So this gives you the automated compliance for that.
Next comes centralized visibility, which delivers unified oversight into the secret management for you. Because now it is not just your internal secret that you are going to manage through this service, it's also providing your external secrets and third-party secrets. And then when it comes to security, think about the scenario we are talking about now. The human is out of the loop from the knowledge of the secret point of view. It is system to system, so this highly improves your security posture and reduces the manual handling. At the end of the day, from your operational efficiency point of view and from the security point of view, you get the secret managed well and secured well, as well as it reduces your potential business outages because one of the important things here that we worked with the team to provide the solution is to make sure that when the secret is rotated, the application doesn't break. We should be able to rotate the secret without breaking the applications. So that's the final result that we achieved by using this new product.
Technical Workflow, Console Demo, and Implementation Details
With that, I'll pass on to Ritesh to give the closing remarks. Yeah, so thank you, by the way. So I think it is a really good insight into what customers' use case concerns are, specifically from a point of view of Fannie Mae as a customer, but honestly speaking, 80% or 90% of these are very similar to other customers. So our approach of working with Fannie Mae was to take all of the learning and kind of apply it so it helps other customers as well, and we have seen great feedback about this feature. So I'll do a quick high level walkthrough.
So there are certain aspects of this mental model of natively integrating with third parties that is slightly different than what we would do with AWS secrets. So in AWS service, I know enough about AWS services that I know what type of secret it expects. And so in this case, there is a little bit of initial configuration to ensure that a specific partner has a specific predefined format. Once that is done, the rest of the workflow, if you have used Secrets Manager in the past, is exactly the same, right? All the great benefits that you get out of Secrets Manager continue to remain the same. That includes the envelope encryption through KMS, the integration with Security Hub, the integration with CloudFormation, the integration with Config, all of that exactly remains the same.
And in addition to, I think what Raj mentioned, the compliance part, everything is audit trail or audited in CloudTrail, right, so everything is monitored. It's similar to what you would see in any AWS service. Any mutation action, any action on the AWS service will be tracked there. And so nothing changes. So I think the intent of the slide was to say there is this slight difference about how you put the secret into the system, but after that everything just flows.
So this kind of gives you perspective, or this view gives you a perspective of retrieval. So there's, as you can see, a customer application, and it is interacting with Secrets Manager the same way, similar to like you could use the CLI, CDK, SDK. You can use the latest launch Secrets Manager agent to retrieve the secret. All of the functionalities remain the same. Behind the scenes, what is happening is the rotation code that was approved and validated by AWS and the partner is now incorporated into the rotation schedule.
So this is not a Lambda function. This is just a code that we run as we assume the role of the customer and run it on the ISPs side, so it will first update following the same process that we do today. First, update the secret in the resource which is at the ISP site, ensure that it's working, and then update it in Secrets Manager. So talking to a point of, hey, application downtime, the risks to that, we are shifting the responsibility over to AWS, so we're saying we will make sure that the applications do not go down in this kind of scenario.
So I think that is a key aspect of it, and there are three points written over here. The last two are extremely important. So the biggest problem with rotation of people wanting to rotate or not has always been, oh, I have to do a lot of work to rotate, right? So this ensures zero overhead in terms of rotation and gives you a complete managed rotation experience. The partnership trust ecosystem, we believe AWS has a really solid framework of ensuring the partners that come into our system are well validated and insured, so we continue to do that. So when you look at it from that angle, we are saying this is a part of ecosystem that is well trusted and you continue to use it to leverage Secrets Manager rotation. So that's where we are at.
So once, in the next slide, I'm going to walk through a demo. It's a recorded demo, so I'll try to talk through it. I didn't want to use audio here, so it'll have my voiceover. So I'm supposed to click this button. I'll try it. All right, so this demo is obviously of the console, as you can see, there is already an admin secret created there. Now you go into the system where if you're not looked at it, there is now a new system called manage external secrets, and you'll see the three partners that are in there. So for example, now we select Salesforce, and remember I talked to you about the predefined format and metadata that you have to store. So this is where you would set that up. So as you can see, it's slow, but it'll go through.
Essentially, all of these items like consumer key, consumer secret, base URI, all of them are already identified as the metadata in a predefined format. So once that gets set up, you go to the normal screen. Of course, the naming structures that your company or your organization ensures that your teams follow will go through that. And then if you notice something here, the rotation is automatically default enabled. So usually in a normal secret, we do not automatically enable it, but it's already enabled. And that admin secret that was created I showed you earlier is the one that is used to rotate the secret.
So now, of course, the secret has been created. If you've looked at the console, you have to go down and save it, and then finally it'll come up. One of the key things that I wanted to show in this demo was if you look at the versions here. Secrets Manager keeps hundreds of versions of the secret behind the scene, but if you look at the version here, you will notice the number E01 at the end. It is now marked as AWSCURRENT, which is if you do get secret value, it is going to return that secret or that value. In the initial setup, this type of setup secret is set up for automated rotation, and it'll rotate immediately after the secret has been created.
So right now what the person is doing in the demo is refreshing it so it starts to rotate. So you see now the E01 is still current, but the new one has been created and now switched to current. So it's already rotated. And so even if, for example, a customer is still handling the manual part of the secret and copy pasting it, it is rotated immediately after creation, which means the new secret is now not available. I mean, no one knows about it. It has less human visibility. So that's kind of the view of it, and so that's where I'm ending.
These are some of the QR codes my team asked me to add. If you are a customer that is looking for a partner integration and the three that you see do not fit the bill, please let us know. Talk to your SA, talk to your team. We'll make sure those are prioritized. And of course, there are tech docs launched as well. So thank you again for joining.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)