Hey, so I'm Ciara Carey and welcome to Cloudsmith's webinar on all things package management and supply chain security. Cloudsmith is your cloud native universal artifact management platform. So let's get on to our topic. Oh, before I start, we're using a new webinar program. platform today. So excuse us if there's any hiccups streaming to any of the platforms.

So let's get on. We know that managing authentication and authorization and a scalable, secure way is like a mega challenge for organizations. A lot of organizations want to move away from long live credentials, like your username or password, even your token, and especially in your CIS. CD tooling, where you're given like a extensive permissions.

Well, you can do this with OIDC or OpenID

Connect. And today we're going to be talking about this, about configuring OID Connect with CloudSmith and GitHub Actions. So super practical, and this is sort of a continuation from our last webinar. In our last webinar, we talked to Rob Godfrey. He's a senior technical architect of the Financial Times, and he led a team that had to deal with an incident in early 2023 where they had to rotate and revoke all their long lived credentials in their, in their pipelines.

After a breach, there was like thousands of, of long lived credentials they had to rotate and it was a huge task. Weeks of work from a team of engineers. And after that, they decided to move away from these long live credentials and use OIDC authentication wherever possible to make their pipelines more secure and more manageable.

So what is it? These long live secrets in our CICD, well, we need

them because they facilitate access to all those cloud services for publishing artifacts for software deployment and cloud resource management. So like a classic. Use case for using long lived credentials in your CICD pipeline would be a user is created with the cloud service and this is we integrate this with our CICD, such as like AWS or, or CloudSmith, and we need permissions to perform actions like push a package or push something to an S3 bookish.

So we, to do, to, to. Create these permissions, we, we create secret in our CICD, like our GitHub actions. And these credentials, these are saved and they're basically just long lived credentials then. And then we use them in as we're running our GitHub actions. And they have to have extensive permissions because they need to create stuff to delete stuff, to update stuff, you know, [00:03:00] they need to do stuff.

So they need like a lot of permissions. And the problem with this is that like if they do leak. It, the blast radius is quite hard. So the main problem with long lived credentials are they can leak. Any credential can leak. They expire and then you have to you break your bill that way. So it's kind of hard to manage.

And often these credentials, it's, it's, it's, It's common for them to be reused. So that increases the risk factor there. So what is OIDC? Well, OIDC stands for Open ID Connect. You don't have to completely understand it, I'm not for sure I fully understand it, but I do know how to use it. So but here's the two too long, didn't read the version of it.

So we all know how to we've authenticated using OAuth into services using Google, Apple, and Facebook. We're kind of used to that. Well, similarly, similarly, OITC allows like a [00:04:00] trusted service, like OIDC identity providers, like GitHub actions. To authenticate into other systems like CloudSmith. And it's like a, in a non interactive way.

And like by creating a short lived JWT token. So you, you can request these tokens on demand and they're good for like. 19 minutes or 15 minutes. I'm not really sure, but a short amount of time and then they expire and you don't need to worry about them leaking. So they keep you safe for production and you're able to do this, this process at scale.

So now that I did a quick introduction, let's, let's show how you would configure this. using CloudSmith, configure CloudSmith to use GitHub actions so that GitHub actions is the OIDC identity provider. So our workflow would be like with our workflow would be in CloudSmith, we've

set up a service account and we'd give it the right permissions and also in CloudSmith, we set up our GitHub OIDC identity provider for the CloudSmith organization.

And then in GitHub Actions, we update our GitHub Actions to use the OIDC. And then we trigger a build just like we would trigger something to happen. And it should pull down those creds to use with our CloudSmith Actions. So let's actually do a little demo. So I'm going to Share my screen. Forgive me, this is a new platform.

Okay, I'm going to share my screen. It's happening. You

can see, I've been studying this handshake thing with OIDC. Like I was saying before, we configure our cloud provider or our service like CloudSmith to trust GitHub Actions. There's some sort of handshaking going [00:06:00] on. And when we're running our job, it'll, it'll request a token and then it'll CloudSmith will verify that this is correct.

Yeah. You can So let's see. So this is our Cloud Smith repository that we're going to use here. I'll just, there's a package in here. I'm going to just delete it.

So first thing we need to do is to make sure that we have a service, service account. So here is our account. So I'm going to use this one, GitHub actions to To, uh, with the permissions in to run this in GitHub actions. Sorry to this. So the service service service account is called GH actions.

Okay. This is my repository. I have my service service user, and now I'm going to make sure my my Service account has the right privileges. So in my, my repository, I'm going to go to access control

and I've given the correct [00:07:00] privileges, right privileges to to this guy here,

and now I'm going to set up OIDC, so I've so I'm calling it, so here I've already configured it, calling it gh2, and this is the URL you used to set up get up actions as the identity provider. It's the, it'll be the same for everybody. And then I'm going to set up my claims. Now the claims are actually really important because if you don't set up, set them up, you're giving like broad access to other runners on get up actions to possibly also have permission to, to do something to CloudSmith.

So I have Restricted it to repository owner, which is me and that's my GitHub repository owner. And then I have selected my service account, my GitHub Actions service account as as the user. Okay, great. So I have set up GitHub Actions to have [00:08:00] permission. to authenticate into CloudSmith. And now I am going to go to my GitHub my GitHub project.

So I have robbed this from Dan McKinney. Thank you very much. And it's just a little project to build a Debian package. I'm only interested in the workflow. So there's a few things that you, that are important. Okay. So. We're going to be using the CloudSmith action and we're going to trigger it on a push.

We could have just triggered it on anything, but we'll trigger it on a push. And this part is really important for, this is actually necessary for the OIDC thing to work. You, you gotta, you gotta, and give the GitHub identity provider permission to write the, JWC token, which CloudSense will need later on.

And so we have a job here to build this is just to build that package. And then we have a job to publish. And so, so this is the OIDC stuff here. So I, you need to have these lines, these two lines here to request the token. Yeah. And then post the token and then it's available for anyone below that can use that token and we need to set the environmental variable to be CloudSmith API key so that our CloudSmith action will will read that later on.

Okay, and then we have we're going to push our package to CloudSmith and that's what this bit does here. So, okay, let's see. Let's get it going.

I'm just going to force it. We run all jobs and you can see here, what I expect

in my repository

is that push a Debian package to this repository using my

Using the GitHub actions here, and it's going to use OIDC to authenticate. And I've set that up earlier. Okay. Yep. Yep. Yep. Yep. Yep. I'm going to run it now. If I had, obviously, if I've made a change if I push to change, it would automatically run.

It's pretty quick.

And to go back to the claims bit, I think it's really important to emphasize that you really should have a claim in your in your, in your OpenID token, you should really have set a claim. Otherwise, you're going to set too broad provisions. Okay,

so now it's built that it's going to publish it.

Okay, so you can see here it's published it and you can see the person that's published it is our service account gh actions. So it all looks good. I'm going to run this again and just show you when I that it will fail if I don't have, just, I always like to see things fail just so that you see what is working and what isn't working.

So I'm going to disable. This GitHub action now. And when I run it again, this will fail. Okay.

Now, we run all jobs.I probably should have just run the publish bit, [00:11:47] like a good fail. Oh, okay. Come on. I'm rooting on you to fail now.

Oh, yay. Oh, boo boo. But we knew this was going to

fail because we we updated what GitHub actions was permitted to do. Okay, great. Yeah. So I hope you've gotten something out of this. We've showed you a workflow. Oh let me on share back. Hey, so oh, I, so on this, so I've showed you a workflow how to use GitHub actions with Cloud Smith to, in a, using OIDC.

It's like a more secure way so you don't have to store your cosmic credentials in your in your GitHub actions. In a, in a secret. And this is a manageable, secure, scalable way of managing your authentication and authorization for your organization. Yeah. I'm going to see if there's been any questions.

Okay. I do have a poll, but it might be a bit late in

the day to do it. Okay. I'm going to try I'm going to publish this. Oh, there's two votes in. Okay. Okay. So I have a poll. There's two of them in do you use OIDC in your pipeline? So it's like. Most people don't and I think it's, it's sort of new, you know, and actually it's, it's, there's a lot of work in updating all those all those long live credentials.

Totally understand that. So, and not all services provided. And let's see the Oh yeah. Have you ever had to, my other question is, have you ever had to revoke? Or rotate keys after an incident and it looks like everybody has. There are so many people voting, but I, I think it's, it's a thing you have to do.

You know, things happen. People publish things by mistake. The services you're using might have a breach. These things happen and we need a, a better way. We need a better way. So thanks for coming today. I hope you've gotten something out of this.

And are, we're actually going to have a webinar and only a few weeks time with Spacelift on how to securely deploy things using infrastructure as code.

So thanks for joining today. And I will, and that is on the 5th of June and the, it's called enforce secure automated deployment practices using infrastructure as code. Okay. Thanks again. Bye!