I'd like to thank everyone for joining us. Welcome to today's CNCF live webinar, where to begin your dev-centric cloud infosec journey. I'm Libby Schultz and I'll be moderating today's webinar. We'd like to welcome our presenters today, Guy Eisencott, Product Management, and Ashley Ward, Technical Director, both with Palo Alto Networks. Just a few housekeeping items before we get started. During the webinar, you're not able to speak as an attendee. There is a chat box at the top right of your screen. Feel free to drop your questions in there and we'll get to as many as we can. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct and please be respectful of all of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF online programs page at community.cncf.io under online programs. With that, I'll hand it over to Guy and Ashley to kick off today's presentation. Thanks very much, Libby. So yes, here we are. Thanks to CNCF. We have this presentation. Now, what is entitled? Where to begin your dev-centric cloud infosec journey? But when is infosec ever meant to have been dev-centric? Isn't this just pandering to developers who should have been making their work security-centric from the beginning? I'm Ashley Ward. I'm technical director of the office, the CTO and with me, though, is Guy Eisencock. I is actually a senior director of product management. He's the one who knows what he's talking about. Instead, I'm just the aggressive, angry one in this conversation. So, Guy, here we have a cut-out from the CNCF landscape of security companies. There are oodles of them. We've got security everywhere. Any different little bit you might want, there's a security company. So what's the problem? No problem. Here are all the solutions, right? You'll be aggressive and I might be passive aggressive. Stop it. I'm trying to poke you. Good luck. I'll say this. I think what I think is very interesting about the landscape is that it really demonstrates the fact that we have developers on both sides of the eye. We have security developers that are working tirelessly to try to inject their long thought processes and how to eventually implement security controls on a very rapidly growing ecosystem. On the other hand, you have growing populations of developers and application developers, web developers, infrastructure developers that have hands-on access to the core infrastructure that's going to run applications for some of the biggest companies in the world. So what happens when you have talented developers on both sides of the spectrum is this fantastic landscape where companies and individuals even in individual communities identify very granular problem spaces and tackle them head-on. As a developer, sometimes you don't have the privilege to whine. You have the privilege to try to solve things as they are. Maybe I'm being too optimistic here, but what are your thoughts on how wide this landscape is? No. I completely get what you're saying, but at some point, what are the challenges? I mean, isn't this like you said, seeing about security people whining, isn't this what's the problem here? We've got all these tools coming out. Why is it such a big deal? Yeah, good question. I don't want to boil this down into something that's being too simplistic, but I think really that the title of this talk is going to be not only what should you do, but where do you start? I think a lot of people maybe that are attending this talk and I've definitely been on this trail starting our startup about two and a half years ago is what is going to be best of breed and what's going to be good enough when you want to build an enterprise-grade web application that's hosted on the public cloud. One of the complicated things as a developer coming into this space is that there's so much to choose from and there's going to be so little that you can trust an external vendor or a third-party service provider to give you compared to things that you can either mix and choose and build your own best of breed. If I'm speaking to myself two and a half years ago as a technology leader and a product leader, I think the biggest challenge has been where do I actually start if I want to build really secured cloud infrastructure? That is interesting because actually one of the things I was then going to hit you with was that well actually the research has been done to show that we're not getting there. Our Palo Alto networks have a Unit 42 research department, but there's also the Bridge Crew research as well of course which is just as valid and may come up with these numbers. Now I always worry when we display numbers like these that we're trying to fear monger and so I immediately go we're not trying to fear monger, we're trying to say that the issue exists. So these seem like really simple things. I mean I get that we're still not doing them but you know I speak to CISOs regularly and a CISO would look at this and say well why isn't this happening? Shouldn't people just know to make sure that cloud databases should be encrypted? I mean why is this such a big deal? Yeah and I think you're going to take the side of the security practitioner and this conversation. I'll try to take the position of a developer or again a technology or an architecture leader. I think what research that we've done internally in Bridge Crew and now we've seen done on Unit 42 and others is just take a look at these consistent numbers where if we look at configurations, we look at vulnerable images, we look at misconfigurations on our centralized artifact or public artifacts for helm charts. You can see these ecosystems are consistently misconfigured but not because of human error. For the other exact reason we're trying to make it that simple for developers to ramp up from zero to a working or functioning cloud environment using boilerplate templates. So whether that's a boilerplate template you capture from GitHub, whether that's a boilerplate chart you get from artifact hub, you're bound to get a configuration which will only bring you thus far into a running of working hello world and what happens is that those boilerplates are sometimes not treated as such and this is across multiple ecosystems in our in our landscape. They are getting consistently misconfigured. Have you seen any specific ecosystems that you think are more prone to error than others from a security standpoint? The thing I think you've kind of hit the nail on the head a little bit around that whole sometimes from a security point of view people and it's human nature right to try and just abstract things away or to pigeonhole things and one of the things is about around you know a developer and a security person and we all have these nice it's easier to have these slots for things but in fact that's not that's not how things work we're such a huge field and such a huge subject that you're not going to be an expert in all of these different areas and really you shouldn't be. I mean if somebody was building a platform it's going to have different priorities to someone who's you know building an application even though both of them if they're developing code are developers at the end of the day you know so no I find that really interesting so we have again more more research driven information because that's you know that's how we how we want to do things. We've got this whole notion of we've seen terraform templates we've seen Kubernetes manifest in different ways I certainly can hold my hand up to a few of those on the Kubernetes side of things but from the terraform template side can I talk us through some of these things yeah we'll get to some practical examples later on but just take a look at networking as an example so if you remember you know if you had a non-prem data center just what two three four years ago we had networking engineers that their sole purpose for us as business owners was to go out and capture best of breed infrastructure and essentially hardwire configure it in a way that really makes sure that what needs to be inside stays inside and what needs to be outsized stays outside and what cloud native is done specifically for the role of the networking engineer it's essentially democratized it democratized it a microservice can essentially become a networking edge in a flip of a button and what we saw from our terraform studies is that it's it's not just you know if you think of something like a security group concept which is the AWS equivalent of a firewall rule that's not enough to get you protected if you want a specific workload to be private and not public you have to be cautious of everything else that's going to wrap around your compute instance whether that's the security group internally and then you're going to have your vpcs the way that your accounts are set up appearing there's a bunch of different ways to make connectivity work in a public cloud and that's just AWS and terraform is a surface what happens is what what happens now when you have those microservices set up as individual networking nodes that suddenly have their own networking capacity and networking interfaces and that's where we move right to the kubernetes site right and that's that's a that's an entirely different world where networking is is completely extracted through through networking interfaces and there's tons of great projects that are now trying to help us go through the barrier of the deprecation of things like network pod policies and start to go to a more a more standardized future with with with some some great insights into into how you can consistently invoke networking on a variety of different edges on on your networking cloud but networking is not alone right you mentioned databases that's that's another one so i think we're past the point where we have the notion that we need to maybe encrypt or or just i use use standalone networking excuse me databases that retain data in a way that that is consistent with with how we want to preserve private information as an example but databases are also becoming this entire world where it's not just the dba that controls the configuration of the database you have you know networking for that database right you have logging for that database backup and recovery for that database all of those parameters now become knobs and switches that can developers can turn on or off and and potentially harm the the the overall posture of of how data is handled you know you're so right and the sad thing is is that that's these were all things that were abstracted away or roles or shoulders of giants that were you know people did before i i smiled there as you were talking because i have a very close friend who's who's a dba and and you know our relationship from the very beginning was always he would come to me probably to ask me for more file system storage uh because his database would just consume everything that was there but but you know he would then have a similar relationship with all the different applications that would run on that shared database and people would forget that actually there was a whole load of effort that i put into for the operating system he put into from the the database the relational database at the time a very famous one that everyone knows and loves our relational database all the settings there and then the different schemas had different people who would look after schemas but you've got all of this thought and intellect that goes into it and you mentioned backups and all that i mean it's it's a huge thing that was done previously i'm not saying we go back to these glory days of multiple layers what i'm saying is that a lot of the time there were many decisions made that were were perfectly in keeping with stuff i mean in kubernetes manifest land runs as root or privileged containers i watched a really interesting talk one kubicon which was about here's what happens when you run a container as root now as somebody who who had root access and very proudly uh you know had they got root t-shirt that was me i i had root i was the man in charge as somebody who did that to me having root was it was clear it was super user access but actually it was really interesting saying well if you grant root privileges to a container and then have a container be able to make use of those then actually bad things could happen and the whole audience loved this talk and while i'm going am i a dinosaur this is if you grant something root but it's because it's not clear because that wasn't the life that people lived of having to manage root access and who can do what and what happens but the other thing is you you were very kind and said that you know it's not people who necessarily do this for the kubernetes manifest i'll hold my hand up and say that i've probably done those top three quite happily at many times in order to try and get things working certainly i know i'm all sharing those networks one thing for number three sharing a host file system i think i've i've certainly um i've been bad at doing that type of thing uh myself so listen what then is the answer with all of this what can we do to try and make things better i mean we've talked around the problem and now you know you come along this way but i don't think it's just a tooling thing come on what is it that we should be talking about i'll give you my my point more my perspective on this and and i think you have your your individual and and thoughtful one as well but i i'd like to look at um if we started back on the landscape now let's focus on the individual team and um and we have this abstraction of a development lifecycle which which is purposefully uh abstract away some of the complexities of CICD pipelines because we're we want to start to think about um development life cycles as a spectrum we have on our far left the development stage we we're going to break that down in a little bit but if you think about how code gets composed gets um um collaborated between teams gets reviewed that's an entirely um new uh newly found process the teams that are being thoughtful about how they want to make sure that their uh their good code arrives downstream and not the bad code are putting more and more emphasis on how do we create developer guardrails that are not restricting um as from building but are actually helping us to prevent uh the miserable mistakes that we can do downstream and then on the far right and we'll get to the middle in a sec we have a runtime and and from my perspective it's usually from a security standpoint it's really uh where it's probably too late right because if we had you know our our best and brightest um building our business logic uh reviewing it analyzing it designing that it's production ready testing it naturally um by the moment it gets into into runtime and we have the most sophisticated tools out there that are trying to capture the misconfigurations and to make sure no one gets in um usually the effort to uh roll those uh back and make sure that a a misconfiguration is no longer in runtime is something that could cost us a lot it could can cost us a lot in in our SLAs and SLOs and it can cost us a lot in human effort to make a uh a business logic that had worked previously uh work now with with injected insights from runtime and this is where the middle part comes into the picture and that's where I think the biggest promise is over time is seeing teams that are making the effort to take that initial portion of code review and making sure that that code gets reviewed in variety of stages with proper context that mimics the best way that a runtime environment will behave whether that's in a CICD process a lower grade production a pre-prod if you will those are the types of processes that have become become common knowledge but making sure that they get security verified and and identified for potential issues using some of the tooling that we've seen previously is where I think the next big leap in terms of security maturity we're going to see amongst uh cloud native teams that's that's really interesting because usually from a security point of view it's all about and again I've got friends who laugh at me as soon as we say shift left it's like I get paid every time I say shift left and so it does feel sometimes you go shift left as far left in fact make up more left and put it even further left than we can but actually you've called out that certainly that develop phase is really important but you've got a whole load of value and distribute and deploy that's that's really exciting then for everybody who's on this call this is taking that's the cncf security seg the special interest group that's the white paper we've pulled those out from and I will call out a friend of mine a colleague actually but a friend as well Vinay was a co-author on that so really exciting for that part but listen sorry guy I've gone on sidetracked again but go and dive into a little bit more around this one yeah so if we we now double click maybe one layer deeper into into that previous slide and give you a little bit about how we at virtual kind of tackled it when we try to identify the human and technical interfaces where it really becomes very valuable to start getting deep contextual insights around how infrastructure gets rolled from the point it it was fetched from a a module that was publicly available like the terraform registry or the artifact hub to the point where it gets deployed in a production environment and and we went really really deep and we really wanted to start with the individual developers IDE because it's you know it's amazing sometimes we forget about how much control and how much access we give the individual developer when it comes to cloud native apps you mentioned uh root access before in kubernetes um if you think about a developer that's building a net new application from scratch they're going to essentially when when configuring the code that eventually runs the manifest for for for that uh for that kubernetes cluster workloads um you understand that a lot of the decisions are going to be made probably weeks or months before um before that uh that gets eventually into prod so that root access that appeared in runtime on the end of the process actually appears all the time on the individual developers IDE and when you go into that type of mindset and you identify there is a lot of complexity uh that goes into building out secure by default infrastructure you identify the ID the individual developers IDE as an opportunity now i'm now i'm going to speak from a security mindset um and say we can give developers best practices and how to set up their local environments and we can give them even further guidelines and details on what types of linters testers uh verification tools they're using um on their individual workstations and this is where i think organizations are going to have to go beyond just uh requesting or requiring people to to use these tools on IDE but this becoming uh the facto standard that's interesting because that's certainly that's that whole um primitive testing and the type of stuff that you can do frequently and often and you can do that in your IDE um and it ties in again with that whole thing you mentioned before which is you know when we look at a developer there could be a developer who's doing infrastructure as code and somebody else who's writing a different an application or doing something there because that was something i found very early days writing um well puppet or chef or whatever at the time and about going okay well why don't i have some limiting take place just as you mentioned that's that's really exciting i like that guy yeah me too um let's maybe take this real quick and kind of merge between uh pre-committed pull regret pull and merge request processes um and this starts with uh we had an earlier conversation about github's you and me and we we talked about the opportunity that uh gith as a platform regardless to what gith platform you're using is introducing to uh automated security testing and and one thing that we really like is the fact that we can invoke a conversation that's triggered by automation and that brings together developers to make a decision as part of coding and when you think of the request process you know we're used to building naturally the the you know the the front the front end servers on one end the back end servers from the other end we all meet together at the pull request kind of do our end to end testing making sure all of that works that's a conversations teams are very much accustomed to one interesting um uh recommendation and and uh a pattern that we're we're seeing some of the more advanced infrastructure and platform team taking on is using automation to invoke that conversation by identifying issues together um uh in front of a group as part of the pr process so if i am a individual developer and this automation testing automation that i've done uh introduced a misconfiguration detection as part of my pr process this now invites especially in our asynchronic world a conversation about how do we want to address a specific type um of configuration as a as a life cycle in our application um so that's something really really interesting that we see teams already implementing and and naturally that that kind of takes on and progresses into cacd and if you have centralized cacd and you have multiple developers that are kind of uh you know looking at those cacd logs testing out and to see variety of ways to automate and use the variety of different ways to build out pipelines to uh to secure different types of workloads that where that's where a conversation can be done based on metrics and stats because in cacd you can you can docker build so you can identify the vulnerabilities and you can mimic a pre-prod using um using a dynamic analysis or or other types of capabilities that are only available at that stage so um these might seem as two different conversations but they have one thing in common where we're bringing in more context in front of more people for them to have the decision uh made communally um and not an afterthought once the infrastructure is already deployed right yeah that's about that ties in that doesn't matter then I mean you mentioned there's various different various different source code providers various different even gate methodologies as to what kind of workflow you're using there but either way that ties in doesn't it mean that means all of a sudden you're actually having that conversation you're opening up and you've got that information to say to make an informed choice I mean even if that informed choice is no we need to carry on with this that's great but at least it's not happening in this diagram at that very last run time run time phase where you would then be throwing up blockers or doing anything that's like that so that's that's really good I mean so that we've got here and that that's said quite paper that it's really really good we've taken those those graphics from it and presented in a single in a single place it does look pretty busy here I mean if I'm if I'm coming to this is that angry security guys I'm as I started out this conversation as I mean this is difficult right there's there's an awful lot to this what what type of way I mean where do we get started with this yeah like like everything I don't want to oversimplify especially with with some of the great work that's already being done in CNCF with regards to security but we do have a couple of best practices that that we want to kind of lean towards when we when we look forward into into into implementing development by the security development by default I think it goes back to ownership and one of the things that that's interesting for me to observe is to see the fact that teams that initially had DevOps functions I think I'm not aware of a company that is cloud native and doesn't have a DevOps function is now starting to break away into more granular sets of ownership with regards to platform and infrastructure and making sure that the secure configurations is something that developers consume from a secure location the same way as they would consume binaries and and use that to build safe and secure platforms right and and I think that's a trend that we see going forward and as as far as I can tell we can see infrastructure team more on the bottom part of your screen focused on creating the development in the right runtime infrastructure for people to be able to ship the code as as securely as possible using infrastructure that's prevented and then platform teams are developing the those paved paths or paved roads for infrastructure for excuse me for for web developers and and another server side developers to be able to consume small rationalized bite sized pieces of platform for them to naturally innovate guy that's that's really good and actually something you didn't know because it's not something we've ever spoken about that ownership piece to me is that is a huge thing I actually I actually think that's a major thing this miss misunderstanding about what ownership means and the continual development nurturing and loving of whatever it is that you have ownership for I think there's a huge bit there so it was really actually really good to hear you you talk about that part now where you know we're here there are people listening to us they don't want to just hear about why I think what you've said is amazing for where do people get started yeah so we wanted the takeaway part to come as early as as possible in this talk so we took us 30 minutes but we're here now I think you know these are universally biased towards my and Ashley's personal experiences but if we look for a place to start these are these are some of the guidelines that we've practiced internally in our teams and are now advocating in our current roles let's start from the left let's shift to left and start with collaboration which I think is rudimentary goes without saying but there's needs to be a way to have meaningful technical discussions that happens between developers and security and cloud is the one that pushes us to have those discussions without overhead for management or architects god forbid and really have that as a straight dialogue I've mentioned the ownership model and I think the the CIG paper from CNCF breaks out the the initial path for that second actionable piece of advice we'll get to this in a quick demo in a sec is start with visibility start with identifying you know the the types of configuration frameworks the types of infrastructure that your teams are using and if you're not aware of them there's great great tooling out there to get you started to get create that initial inventory of what people are using I've found that the best way to actually find out is just talk to the people themselves run a quick google spreadsheet make sure that you have a tally of if people are using clouds or or configuration frameworks that you're not familiar with and if you're still in need use technical means of identification and discovery those will get you a long way next part of that is guardrails so once you identify what you want what you want to start monitoring is developer guardrails whether those are in id and are all the way down to runtime and we're big proponents of embedding those insights and tooling as as early as possible in the pipelines I've talked about IDEs pull requests feature request scanning is fine CICD probably more prominent now get get that visibility as far left as you can that will probably bring a long ways to bringing the detection of the solution and the identification of the of the problem into into the rights of the right onto the hands of the right people and last I think what the landscape offers us is the option to choose between building your you know building from scratch leaning on the shoulders of giants and using open source that this community has cultivated in the last five years and last don't hesitate to use commercial tooling you can select the best of breed to put you know the the benchmark on where you want to go and then you know close the gap based on your your personal preferences and and how much of a capacity you are you're willing to intake in terms of risk appetite but so I mean obviously I mean I'm wearing the t-shirt so that's where I come from but I look at it as so I was a customer before I before I came over and worked for hours and hours and not going into anything on the product side but my differentiating the value that I added running an open shift platform or bringing the financial services organization into cloud wasn't the security aspect it was the essential part of what we did but it but it wasn't it wasn't what added by my end customers didn't care how that I'd written the most amazing or engineered the best solution it was it was about it was about doing the right thing so listen we don't need to go in obviously we're not we're not going to have been a product we're not trying to do that but can you actually show us something around this I mean what does that actually look like and I'll stop sharing yeah and I'll start sharing so if you're not familiar I'm personally invested in an open source called uh check out actually do you see my screen now I do I can see your console window there beautiful so let me spell it out for you so check off is an open source utility one of four that are associated with hands on for the past two years and check off is a policy is called framework that we've been working on since around 2019 it was started out by one of my co-founders Brock Schuster who has been building and developing open source software since he was probably 14 and he helped me identify about two years ago the fact that one of the initial key components to identifying misconfigurations and being able to resolve them in the correct location is to be able to have a portable and a lightweight utility that provides that visibility wherever you want to use it and that is I think probably the most important uh point for for people that are getting started start with something that's portable and lightweight that can teach you where you want to get started so check off I mentioned policy is called what what does it do it scans using a a technique of both study code analysis and also a graph based dynamic analysis manifests of configurations in cloud native applications so we've mentioned terraform cloud formation azures resource manager templates arm templates from the cloud native side it also does a cdk if you if you're into that as well serverless um as well but it also goes into uh kubernetes and helm as well so it really provides a nice broad coverage of some of the most popular configuration methods out there and the nice thing about check off and and if you've used you know naturally kubernetes or terraform in the past and docker it follows that design pattern of you can run it locally on your workstation it's actually a python based tool so you install it in a simple in a in a simple uh pit command um and the nice thing about it is you can run it locally and start to kick the tires based on your own um own code and I have maybe let's see one one scan so check off I've already installed it I'm pointing it into a directory that I have locally that's storing some of my gcp manifests and and I'm running the scan so what check off will do once I run the scan it will um look into a variety of files that we have in this case defining google cloud uh google cloud uh um uh configurations based in terraform and it will um run them through about I think it's almost 900 or 1000 policies across all of those seven or eight frameworks that I've mentioned previously and what it will do it will start to flag um varieties of configurations and identify if those individual files are configured correctly or incorrectly so very very straightforward um I run this locally these are files I have local on my on my mac uh past uh past instances look like this and then here's a failed instance not to get too much into the weeds of it but essentially what what we did here is we analyzed a uh resource block that defined in this case a sequel database in google cloud and we started to resolve all of the different attributes in that file um so we looked at the database version the region the region and the individual settings and you can see all of these are are set up in terraform code against most of these we have verification tests most of them aimed around security and compliance uh but some of them are around also uh reliability and cost and the nice thing about them is we've actually written less than 30 percent most of the checks in in checkoff today are actually community community um uh source we've had people from some of the biggest companies in the world run checkoff over the past two years and find you know the craziest and and anomalies types of findings you can find and by their journey into creating safe infrastructure uh checkoff was uh was uh their weapon of choice to be able to to start to identify some of these issues um the nice thing about it I mentioned it I run it locally I can test it no one needs to know that I was um out of bounds by uh defining a um a bad bad certificate um on on a database or I wasn't using the right configuration uh uh properties actually any questions you've seen this right uh no well I have seen that one part because I did do that install I downloaded and installed checkoff myself and ran it against one of my terraform templates and like you said the nice thing was it was actually having the block to say hey this is what it is and then exactly as you've done it was that thing of going well nobody needs to know what mistakes I've made locally I can then find out and learn more about it myself it's very nice exactly so we didn't open source and community source only the policies but we also decided that we want to fully open source and and publicize the documentation that went behind the scenes so we had our you know our over a hundred maintainers probably more than a thousand um core users that were constantly providing us valuable feedback into how to properly identify and and fix issues based on what they've been seeing in the field um so we collected that information and we logged it and we've collected that I think one of the most comprehensive sets of data sets of how to identify and resolve issues in in in all three uh cloud providers um so this is a completely open uh resource you can utilize and the nice thing about this is one once you get this naturally deployed into uh something like a github action and this becomes crowdsourced um developers have a single point to click to identify not only the problem but also uh the fix so we we wanted we want to check off to be something that everybody can use and everybody can have visibility to uh so it's really built in that really consistent design pattern where you can I'm going to check off minus help to show you some of the variety of options you have um to to be able to deploy this but you can essentially run this on a variety of uh scm's you can run it as a github action as a as a pipeline task in bit bucket uh negatively in your in your github runner and probably any type of uh ci tool you can imagine so really easily um uh exportable into all of those uh popular ci platforms encapsulated into a single docker uh can be run essentially anywhere and provide tons of value as part of a ci cd run um especially for a smaller team that's looking to to get um get that insight before issues are deployed into production uh you can see we have the varieties of um of be able to run a run a full quiet uh session with the ability to uh skip individual checks or to run just specific checks uh we've recently introduced the ability to do uh image scanning natively and variety of ways to kind of fix and and and instantly mix and match based on your uh individual preferences uh the the overwhelmingly uh popular um usage pattern would usually be someone who's probably sitting in on this webinar peep installs check off identifies that it gives them value locally and then uses some of these advanced options um to identify the best ways to uh to use it in their uh ci cd pipelines so that and that's the thing so you by by having that help that they help format there to show us i mean even even me as a luddite i can see exactly how i could make use of that as calling webhook to call check off to have that result and even if then we agree to we're going to we're going to um that whatever the failure was actually it's acceptable because for whatever reason i've decided my business risk is such that this is okay then then it's easy to then we either skip that check or continue with that check or however you want to do it but the important part is that visibility and everything is is absolutely there that's that it's really cool yeah one thing i last one thing i want to show you i know we were kind of running out of time we've done one last thing which is to mount check off on a very popular code editor visual studio code you might be familiar with it's also part of a part of a very recent launch coming out of github around code spaces if you're familiar with um but if you're a vs code user one of the ways to infiltrate and to get into into id and to make sure some of those valuable insights arrive into the desktops of developers anywhere everywhere is through this uh through this extension that's that's also fully open source and accessible to our community and what this essentially does it it mounts on top of a vs on a vs code that's running and analyzing already analyzing your hard written infrastructure as code and it kind of annotates the problems as uh as you compose as you run the code so in this case i have a couple of my managed kubernetes uh files here on hand you can see i have an azure kubernetes file and an amazon one and a gke and a google one as well and once i have the extension wired here on the back end you'll see that i have checkoff scanning here on the on my bottom pane and what checkoff will essentially do for you as a developer even if you have you know zero tolerance to security people um reviewing your code and telling you what you need to be doing it's going to inject those insights and those over almost a thousand policies there negative coding experience it will do so by annotating the individual resources listing out the variety of problems that may have been found in a much more pleasant way inside those code manifests and it will even go as far as giving you the ability to single click fix or generate a skip comment for select instances of configuration so you can use the drop down point that your resource of choosing and then with a single click of a fix add a missing attribute for example to enable logging to disable the cube dashboard and just to make sure that your settings are aligned correctly if you're interested on where these misconfigured files came from they actually came from another open source project by brew true which is terragot which will give you the opportunity to kind of use a vulnerable by design set of files to train and educate yourself about how misconfigured code might look like and use something like the checkoff plugin to be able to to analyze and to identify the best ways to fix or resolve the variety of issues that can be found in in a popular manifest like like the public AKS cluster that's that's very cool and so this is and you know to be clear to everyone this is a CNCF talk we're not here pitching a product this is this is the open source right this is the guy that confirmed this this is the open source one that I can go and get right now absolutely uh all all of all brew true uh open source is Apache 2 license so you can take it do whatever you want with it we'll be happy to to get contribution back and and to let and you know let us know how it works that's that's very awesome I like that a lot yeah so I think that's uh that's my portion and we can start wrapping up I think so I think I think we've got a final slide just to see us out but actually at this point this is when everybody should be typing lots of questions in there I see that we've had one coming already but this is your opportunity while I share out my screen uh and get away from that last slide so let's recap this while everyone's thinking of their very difficult questions for you hopefully um what what's the benefits to all of this we've described we went through a nice bit of us chatting we've seen some really cool stuff thank you because that is the first time I've seen a lot of that cool stuff and now what's the benefits go yeah so maybe let's quickly frame this approach as people are typing on typing in their questions uh we've singled out policy as code in in this quick demo and we're we're kind of playing through to to that uh to that end goal but if you think of policy as code the nice thing about these standalone utilities they give you the opportunity to test it yourself um download locally run it against your actual code um and if you don't want to you can take a something like an extension that gives you some of that insight directly into your into your coding experience why is this uh amazingly awesome for people that are doing cloud native development um it's powered by a community just like all of the other tools that we love using like kubernetes terraform and others and it creates a repeatable process for you you don't need to run that cli over and over again you put it once into your uh into your ci process you deploy this extension once into your vs code and you're suddenly protected and your code gets so much better than it was before second biggest benefit i see is the fact that you are uh you're conscious about the fact that there's going to be issues that you're not going to be able to fix but it's going to get you much much faster to fix the ones that do have a fix and um and we can spend you know eternity um creating um bills of uh of open source materials that we can't repel we can create spreadsheets on spread on top of spreadsheets of all of the vulnerable packages that we might have buried inside our package json in a repo and we can't replace because it's running our code but we've restarted by focusing on the configurations that we can literally change by adding one or two lines of code that will just bring you so much faster into into much more secure and robust by default infrastructure uh cloud infrastructure um third benefit is that when we introduce some of these tooling into areas like our IDE our pull request process we're making sure that they don't arrive into runtime if it's in runtime that means friction that means an application needs to be changed to be altered needs to be shut down in order for us to make it slightly more secure that's something that most business don't have a lot of tolerance to so as as we pull those insights much deeper into our development life cycle that's what is essentially going to bring us into a more robust and insecure by default infrastructure cloud infrastructure so and to me that's the that's the big one and everyone who's listening can can breathe the sigh of relief you don't need to listen to this crazy scotsman anymore but that's the big one for me is that that the friction there's one thing trying to present something to go into production and not knowing that you've got these holes or that they're going to be picked up or someone's going to be shout at them but actually it eases it a lot more if you'll yes well i've i'm aware fully of all the issues and this is the only one that's a security one and here's why that's necessary or here's the risk associated with it so now i find that that was really good guy thank you very very much i really do i love talking to you so it's really good um thank you for letting me bully you at the start and i've not seen that demo so i really enjoyed seeing that demo thank you i do see that we've got a question in there lots of people saying hello which is nice hello everybody there is another question um i'm going to read it out because then you need to answer it guy if i find issues using check off and i don't own the template what's the best way to get the other person to make the fix yeah um definitely definitely a good question that's going to be on your mind if you're going to try to implement check off so the world kind of splits into two problem spaces one is going to be the infrastructure that you have composed and owned and the other is going to be the public modules and artifacts that you've downloaded from a hopefully a secure location from the public internet the first cluster our first group is very very easy right so this is infrastructure that i compose i own i can fix them directly i don't need to ask anyone uh should be pretty straightforward um nice thing about check off is that it's fully aware of encapsulated modules and variables that are used locally so if you fix if it identifies a problem you'll be able to identify it all the way into the variable that um that it originated from that second cluster is a problem um and that's where um platform infrastructure teams use check off on a day to day basis to identify the templates the modules that are getting used by by teams that are not vetted beforehand and that's uh that's the group where uh we we need we need better visibility on as an industry and and um and one of the one of the ways to make that vetting and to make those changes is to contribute back if you if you're using a publicly accessible module from something like the terraform registry or from artifact hub um you know step up and help us configure secure defaults to those and help us kind bump up those uh i think it was 43 47 percent for most of them um and make make sure more more and more public configurations are in part with what we want our private configurations to be to be adhering to but and in which case i'll add on to that from from the work that i've done along with people in cncf and work with cncf it's the same kind of thing don't feel put off if you want to contribute back that you you need to just do code it doesn't have to be just code the cncf is the reason why it's so successful is because of this community and so this community is about you can contribute back in in many different ways you can contribute back with time documentation holding meetups being involved coming along to things like this so yes absolutely everything that guy said but also if you if you're doing something you see something just just get involved and be part of it that that was really exciting thank you very much actually looking looking at time um i don't see any other questions coming through on chat so i am going to put you on the spot guy what's your favorite part in the whole of the check off and maybe bridge crew but you're not supposed to go into any product stuff so don't go into product stuff but anything from check off what's your favorite thing when you've been using what got you about the whole thing the easy one i think the most inspiring thing has been to see um teams and people from teams that we looked up looked upon um uh three years ago when we wanted to learn how uh some of the strongest and and most talented teams in cloud native are building and and innovating through the community seeing them contribute back to check off so you can recently added a page to recognize some of those rock stars that are bringing in some of that world class uh knowledge and talent into check off and and i think that's been uh especially especially rewarding to see uh to be able to learn through the experiences of you know people who are operating some of the most complex systems in the world through the lens of of their uh code yeah i get that that's that's really good and uh thanks for letting me put you on the spot and answering that really well yeah absolutely couldn't agree more well listen everybody um i know that sometimes in in forums like this it can be difficult to ask questions because it you know that's the way of the world it's it can be obtrusive even when we were in person it was always difficult in a forum like this to get people to ask questions oftentimes it was afterwards people would come up and say hey i just wanted to know about such and such so listen you can reach out to us obviously pal alto networks we are obviously uh happy to hear from you um i'm award at pal alto networks.com guys guys and caught a guy at pal alto networks.com so that's the g instead of the instead of the guy get in touch please reach out anything we can do to help with that that's why we do this right now so guy i'll finish off thank you for your time you did the bulk of the talking and made me look good so thank you very much thank you both so much and thank you everyone for joining us if there are no other questions we will go ahead and wrap this up and like i said the decks and the recording will be online later today so keep an eye out for that and thank you both so so much and have a great day thanks everybody


is a common misconception that depression is easy to spot. Hollywood often depicts it as somebody who is always sad or looks worn out. But depression isn't always obvious which is why so many of us struggle with it silently. Sometimes it means smiling on the outside when we're really dying on the inside. Here are five hidden signs of depression. One, you have habitual remedies. Therapy and medication can help with depression but if you find yourself making extra changes to your lifestyle then it can indicate that you're struggling more than usual with it. I'm going through this one myself. If you are too, you may find yourself exercising more frequently, listening to music more often or doing your favorite hobbies to distract yourself from the pain you're feeling. Hidden depression exists when you're trying to quiet the loud demons in your head. Two, you have irregular eating and sleeping patterns. People with depression struggle with consistent sleeping and eating patterns. You may find you're either sleeping and eating too much or too little. Depression can work in extremes and slows us down when we get little energy from our irregular daily patterns. Three, you are highly philosophical. Do you constantly find yourself seeking a purpose in life? Do you also think about the what ifs and have frequent deep conversations about life and death? Although you sound very scholarly and smart, there can also be a downside to thinking too much. People with hidden depression have a tendency to ruminate about their uncertainties in life. They usually feel directionless, lost and scared. Four, you have trouble with abandonment. People with depression understand how much of a burden it can be. I can strongly relate to this. I have a hard time letting people in, afraid that it'll be harder for them to be there for me when I need their support. I realize I have abandonment issues, but I'm trying harder to be more vulnerable. I realize I can't fight depression alone and neither should you. No one should have to. Five, you're losing your patience. Have you been feeling irritable or angry with others lately? Depression doesn't always have to look like sadness or dejection. Instead, you might find yourself frustrated and impatient with everyone. If you feel like you're at your last draw, your depression might have intensified. Do you resonate with any of these hidden signs? We want you to know that you're not alone and together we can fight depression. Please share your thoughts with us below. Also, please don't forget to subscribe for more content from Psych2Go and share this video to get a free copy of our magazine. With your help, we can reach more people to spread awareness about mental health issues. Thanks for your support, really and truly. We wouldn't have gotten this far without each and every one of you. Have a good day. Thanks for watching.