All right, I think we are live. Hey everybody, welcome to episode eight of Chatloop Backoff. This is a program that dives deep into the realms of the cloud native ecosystem. I'm back yet again, if you've turned in before, you've seen me hopefully this time, little fewer technical difficulties than the last one, but I'm glad to be here again. If we've never met before, it's a pleasure to meet everybody and thanks for joining me today. My name is Jeremy Rickard. You might know me from Sig Release. I send emails once in a while when we do new Kubernetes releases. I'm also part of the CNCF and Kubernetes Code of Conduct Committee, so you may know me from there. If you've never tuned into this stream before, well, welcome again. This live stream is a sibling to the similarly named Clash Loop Backoff. An event that's been happening at the last couple of Kubecons, Chicago and Paris. In that one, two community members are pitted together in a competition, not unlike some cooking contest where a secret ingredient is chosen to accomplish some sort of technical challenge that's the host's choosing. It's meant to be laid back for the audience and pretty fun. There's some color commentary that goes on, but it's kind of interesting because going into it, the competitors don't know what topic they're gonna pick up, so they have no real preparations going on for that. This stream is a little more chooser-owned adventure version of that. The idea behind it is that we're gonna pick a topic and learn it live. So the goal with this is that I have done no real in-depth research into this topic. Instead, I wanna kind of go through my normal learning process, dive into this topic with a fresh set of eyes and kind of go through it as I normally would off stream. In doing so, I hope that we can all walk away and have learned something new. Today, we're gonna be looking at the CNCF incubating project, Keyverno. So you might ask, well, what's Keyverno? Well, that's what we're here to learn today. During this live stream, if you already know about Keyverno, feel free to jump in, answer questions that people might have, help me if I get stuck. I'll definitely be taking a look at the chat and try to answer as many questions as I can. Make it a little focused as we work through some of that stuff, though. If you have questions about what I'm doing, the project itself, feel free to jump those in chat and we'll try to work through them as much as possible. That being said, it is an official live stream of the CNCF and is subject to the CNCF Code of Conduct. So please don't add anything to the chat or questions that would violate the Code of Conduct. Basically, please respect all of the participants and me in this live stream. This video is being recorded, so you're here live, thank you for being here. But the folks that couldn't be here live, we're gonna make this available on YouTube so people can still learn along with us just asynchronously. If you've been here before, we've gone through some cloud native news. Today, I chopped it down a little bit and just wanna go through a couple of things so we can give ourselves enough time to dive through Keyburno. I think it's gonna be a stretch to fit it into the time. We may do a second episode of this coming up, but we'll see where we get. So first up, I'm gonna share my screen so we can just take a look at a couple of things. See if this works, share my screen. All right, so we bring up Safari. First thing I wanted to make everybody aware of, I've mentioned this last couple of meetings, last couple of episodes of this, Kubernetes 130 is gonna be here so soon. It's gonna be here next week on April 17th. So we're less than seven days away from this release happening. It's super exciting. I think kudos to the whole release team. I've been watching it as chair for Sig Release and it's been a really, really cool process to see unfold. Lots of great things happening, lots of cool content coming in. Definitely stay tuned for all the blogs and the feature blogs and the release notes and the actual release blog itself. It's gonna be really cool. Second thing I wanted to mention, and mostly this was kind of to remind myself because I asked this question yesterday and somebody said, oh, it's gonna be coming up in June. The second thing I wanted to highlight was that the CFP or call for proposals for KubeCon North America is open right now and it will close on June 9th. So it's a little bit away, but if you're like me, you may be procrastinate a little bit on getting these things ready. So I just wanted to put a reminder out there. I think it'd be great to see new speakers and new folks coming to this and bringing your lessons learned and all of your cool learnings and experience around Kubernetes and other things in the cloud native ecosystem. Okay, so real quick briefs, briefs through that set of news and kind of updates. I wanna dive into Key Verdo now. So we're gonna do that. Let me jump over to another browser tab here that I pulled up. And I guess this will answer our first question. What is Key Verdo? I see a question in the chat, maybe a question from Chris. Key Verdo versus OPA. I think we'll maybe dive into a little bit of that. And I think you know, maybe a little bit of context about what Key Verdo is, but this is gonna answer it for us. So basically right up front, Key Verdo is a Kubernetes native policy management tool. So what's a policy management tool? Policy management, or what's a policy, I guess, some set of rules. I think there's gonna be some documentation that we can dive into for that. That's generally gonna allow you to apply probably security policies to your cluster, controlling, shaping maybe some organizational policies that aren't necessarily security related, but are things you wanna apply at the cluster level. Okay, so we're gonna do, maybe a little walkthrough of docs first just to kinda understand things. I do have a Kubernetes cluster ready to go for this. It is a brand new Kubernetes cluster. We're using an AKS cluster. I work for Microsoft, but I have a free cluster, so I'm using that one today. So just to start off with, we've got, let's see what we've got running in, just to make sure that I haven't done any pre-work here. So we've got just an AKS cluster. There's no Key Verdo stuff running in this at all, so we should be ready to go. If this fails for whatever reason, we'll spend a Pekine cluster and try to do things locally, but I wanted to kinda go through a real exercise here and see what it's like to do it in a real cluster that allows us to expose things to the internet and do fun things like that. Okay, so let's click on learn more and start our journey. So we've got, Key Verdo is a policy engine designed for Kubernetes, that design for Kubernetes piece is in bold. I think maybe Chris's question, Key Verdo versus OPPA, open policy agent or OPPA, I think is a more general purpose thing. It works well with Kubernetes and I've definitely used it in the past, both as OPA with sidecar piece and OPA gatekeeper. So I'll be able to draw some comparisons as we go through there a little bit, but I think what's standing out to me here is that Key Verdo is a policy engine designed for Kubernetes. So this is probably built from the ground up to be a Kubernetes thing. Another big difference between OPA and I think this is that no new language is required to write policy. So in OPA and gatekeeper, you're gonna be using Rego or Rego, however it's pronounced, in order to do your policy authoring. So it looks like here we're gonna be able to just work with Kubernetes resources and not necessarily need to write policies in the form of some other languages like Rego that we need to learn. Okay, so that allows us to do familiar things like Qubectl get and customize to manage our policies. So that's pretty cool. We can do some GitOps, we can use the tooling we already are familiar with, we don't need anything special on the developer side or from our CI CD systems in order to take advantage of that. That's pretty cool. Next thing on here, Key Verdo can validate and mutate and generate and clean up Kubernetes resources. So this validate and mutate thing makes me pretty sure this is gonna be implemented as an admission controller or admission webhook for Kubernetes. Maybe we'll find some architectural diagrams here. If not, I can sketch something up real quick to kind of walk through what that looks like. But we'll go through the docs. This is a cool one, verify image signatures and artifacts to help secure the supply chain, the software supply chain. So this would be something like you're using Chain Guard and you're producing signatures using or six-door and you're using like cosine to produce signatures for your images. And you wanna verify those things or somebody that you're consuming images from is doing that. They're signing these images to provide some non-falsifiability that I produce this image, not the bad actor over there. And I only wanna allow things in my cluster that have valid signatures. So you could do that with cosine, you could do that with notation which is another CNCF project. So that's a pretty cool pattern that I've seen emerging. We're doing some of that in my day job today and it's pretty nice to see that that's a feature that's coming in key right now, that's pretty cool. Okay, so I wanna look at sample policies before we start trying to walk through the documentation a little more, just kinda curious what this looks like. So let's, there's quite a few things here. Maybe we can pick maybe a simple one. This one, I think it would be interesting, ad labels. You wanna add all kinds of labels to your deployments to be able to define them later on and kind of query for things, make other rules for those. This says ad labels, I see a bunch of ad things here. Those kind of speak to me as mutating things, making changes to the request that's coming in. So let's start with this one and just maybe take a look at what it does. Okay, make the text a little bit bigger and make sure everybody can see it. So labels are used as an important source of metadata. Yep, that's pretty straightforward. If you have done anything in Kubernetes before, you're probably familiar with labels. They're used for services and a whole bunch of other things, key value pairs, metadata like that. So there's a sample policy here and I think we can see our first little dip into the world of Keyverno and we have a custom resource here. So this custom resource is called a cluster policy and the API version for this is keyverno.io slash v1. So this looks really familiar to other Kubernetes resources. It's just a custom resource but it's following that kind of same pattern, right? We've got a spec here. It's very familiar to other Kubernetes resources like a pod or deployment or your service.  This is pretty cool. I think you'd be able to do some visualization of this or use it to organize or better manage your policies and kind of understand what's there. Metadata, the name of the policy. So this is all pretty simple. I think once we get down here, we're starting to see what some of these policies look like. So the rule here is called add labels and looks like we're gonna match any Kubernetes resource that is of type pod, service, config map or secret. And I think up here, this policy performs a simple mutation which adds a label of foo equals bar to pod services, config maps and secrets. So we see that here. We're calling out the specific kinds that we wanna use there, pod, service, config map or secret. If we wanted to add other things here, I think we'd be able to call them out here. And then the action I think we're gonna take is mutate. We saw that up here as well, performs a simple mutation. It's gonna do a patch strategic merge. And it's going to basically patch the metadata section of whatever resource we've got here to add foo colon bar to the labels. So we don't have any labels on this one but we've got annotations. You could imagine that this might also have a labels object on it as well. And then you could maybe add cluster policies to this to add labels to it. So, okay, that gives me a little bit better idea of what our policies are gonna look like. We're gonna have a set of rules inside of those rules. We're gonna have some configuration that lets us match against what we wanna apply that to. And then some actions we're gonna take. Okay, I'm gonna jump back to this page and start with the documentation, see if it gives us a little bit of a quick start to kind of walk through and figure out how we're gonna get going with this. But I think having that little bit of context in the sample policies is gonna be useful for me. Just before we go back, I think this is a good URL to take a look at, keyferno.io slash policies. I'll put this into the show notes afterwards, but there's a whole bunch of different things here. We've got some mutations, some validations, some image verify, some cleanup stuff. That seems like a pretty cool use case too. And then a whole bunch of different categories. There seems like there's a lot of things that you can do with this. This pod security policy migration stuff is kind of drawing my attention as well. Maybe we'll dive into that a little bit. Okay, so back to our docs. Okay, so we've got more info on what keyferno is. It's Greek for govern. That's cool, keeping with the Greek words, Kubernetes. It's a policy engine designed specifically for Kubernetes. Some of its features include policies as Kubernetes resources, no new language learned. So we just saw that, no regal policies to have to do. We can maybe look at a comparison to regal in a second. It can validate, mutate, generate or clean up any resource, validate container images. We saw that on the previous page. Inspect image metadata, that's pretty cool. Match resources using label selectors and wildcards. Validate and mutate using overlays like customized. That's pretty cool. Synchronized configurations across namespaces. Block non-conformant resources using admission controls. So that's what I would typically think of as like an admission controller where we're doing validation. We wanna make sure that our resources are complying to our policies, complying to whatever organizational rules we've put in place. That's a really, really good use case of webhooks like that. A self-service report. Self-service policy exceptions, that's pretty cool. Testing policies, that seems really, really useful. So there is a CLI, the Keyvenor CLI. I think on that other page it mentioned you didn't need any other tools, but I would guess that this CLI is gonna give us a lot more functionality like testing policies, validating resources before we apply them. So that's gonna be really nice. And then of course managing policies using code, as code using familiar tools like Git, customize. Any other tool you're using to apply things to clusters is probably gonna be a great way to be able to use Keyvenor. Okay, so how does it work? Great, there's a diagram down here. This is exactly what I was gonna look for. If we didn't have one, I was gonna go draw one real quick. But Keyvenor runs as something called the Dynamic Admission Control Group, excuse me. And then this links out to the Kubernetes docs. If you wanna get a little bit more in depth into this, talks a lot about what's happening with Webhooks, what they do, what you can do with them, how to write your own super powerful function to extend Kubernetes, to do more in the realm of, admission, validation, authentication, sort of things like that. So it runs as a dynamic admission controller in your cluster. So we're gonna deploy something into the cluster and it's gonna become part of the admission process. So when you type kubectl apply, you enter that admission process and there's a pretty good diagram of what that looks like here. Keyvenor policies match against the resource kind, name and label selectors and much more. So in that other example, we saw that it was gonna match any resource of a specific kind, but it looks like you can do a lot more. You can use label selectors, you can use names. I think hopefully we'll dive into a little bit more about those things. Mutating policies can be written as overlay, similar to customize or as JSON patches. So that's pretty flexible. You can do a lot with that. Validating policies also use an overlay style syntax with support for pattern matching and conditional if else processing. So that's kind of cool. You can do some conditional logic inside of those policies. We'll take a look at that hopefully too. Really curious to see what that looks like. Policy enforcement is captured using community events. Okay, that's cool. So you can get a nice list of audit events for what's gonna happen. For requests that are either allowed or existed prior to the introduction of a policy. It creates policy reports in the cluster. So that's great. We can get an ongoing kind of view of what's there. Okay, so what is a dynamic admission controller? So let's look at this pattern here, right?  You do a cube CTL get pods. That's an API request. Behind the scenes, if you do something like this, you know, if you do cube CTL get pods, that's making an API call to the server and you can do something like v equals 999. And it's gonna show you all of the requests that are being made, right?  So I ran cube CTL get pods and I turned the verbosity like way, way up so we can see what's happening here. But essentially, you know, we're making an HTTP call to API v1 namespaces default pods and then we get back a list of pods, right? So in this case, if we go back to our little diagram, we made that request, it went into the HTTP handler. It's authenticating to make sure that I'm able to do those things.  Then we get into mutating admission. And mutating admission is when we're gonna be able to make changes to that resource that's coming in. So, you know, think back to the sample policy we saw, we wanna add labels to that resource that's coming in. That label addition is gonna be a mutation. So it's gonna go through this mutating admission piece of the admission flow. So we see what happens here is that that request is bumped down to whatever admission controllers that are running, and then this diagram here looks like a diagram of what Keverno looks like architecturally. The pieces up here are really, from this box above, that's Kubernetes specific. So you can write your own mutating admission controller. You could write your own validating admission controller. You can write one that does both and you can plug it in here and register it with the cluster and be good to go and do whatever you wanted inside of that. So this is what Keverno is bringing to the party. So there's the actual admission controller that's gonna implement that interface for us. And then a policy engine, I'm assuming, a controller that's a web hook, something to renew certs and modify secrets, a report controller to generate those reports that we saw, background scans, admission reports, all that good stuff. And then a background controller that looks like it's doing things not necessarily as part of the admission flow, because we don't see any lines necessarily coming directly to it, but you can get a little bit more info here. So the web hook is a server that handles the incoming admission requests. Got that. It sends them to the engine for processing. It's dynamically configured by the web hook controller. So that's what's configuring this piece based off of that configuration. The web hook controller watches the install policies and modifies the engine for processing. So when you see those new policies, it's going to update the engine to do what it needs to do. The cert renewer is responsible for watching and renewing the secrets or it's Kubernetes secrets needed by the web hook. Okay, cool. So those kind of operational pieces. The background controller handles all generation, generate and mutate existing policies by reconciling update requests and the report controllers handle creation and reconciliation of policy reports. Okay, so that's great. So we, Kubernetes supports high availability, I would expect that. There's some really probably good details on this high availability page. Yeah, we can see a bunch of stuff there. So maybe we'll dive into that. We have a little bit more time, but I am kind of excited to get going with this. So let's install it into my cluster and see what we can do. Okay, so this section is going to be a walkthrough for us. So to install Keyburner, we want to install it from the latest manifest. I assume you can probably pick different versions if you wanted to do that, but for all of our purposes here, let's do it from scratch. Okay, so let me clear the screen off so we don't have all that stuff in the background. Make that a little bit bigger and what we're going to do is run this command. So we've got kubectl create and we're going to reference that YAML file that's on the internet. I actually want to grab that first and see if we can see what it looks like. So I've got a directory here that I'm going to store all the stuff in so we can make it available later, but let's W get that and see what we get. Okay, so we've got an index.yaml. I'm going to fire up Visual Studio Code, just so we can take a look at that before we install it. It's always a good idea to look at those things before you fire them up and install it in your cluster. Kind of the same way that curling a bash script and running it probably isn't the safest thing to do, but this will give us a better idea of what's going to happen here. So first thing we see is it's going to create a namespace for us, totally expect that in your cluster you're going to end up with namespaces to store the things you want. Like the Kubernetes specific things are going to be here. If I install some other thing like flux, I probably would get a flux namespace. So this is going to create a keyverno namespace for us. So that makes sense. We're going to store everything there and we'll see that the namespace is specified for all these things. We're going to make a service account, couple service accounts for those different components they're going to run so that they have their own identities. We've got a config map that's going to allow us to specify which resources this is going to operate against and so that gets most everything. Okay, and then we've got a custom resource definition. This is going to be the policy that we saw earlier, probably more than that one. We're probably going to see a few of those things. So we've got an admission report, yeah, that makes sense.  Let's see if we can collapse this. Not a very good editor. Okay, let's just, there we go. So next one is the cluster admission report, okay. Then we've got our cluster background scan. So quite a few customer resources are going to come along with this. Makes sense, there's a lot of things that are going to be happening here. Cluster cleanup policy, yeah, again. But expect something like that. And we've got cluster policies, okay. So I think this is the one that we're going to be most immediately interested in. So this is going to give us the ability to write those policies in a Kubernetes like resource. It's a custom resource, it's not a core Kubernetes component, but it's going to follow the same kind of model of other things that extend Kubernetes with custom resources. Got a few of these in here. And then we can scroll down a little bit more and see what else we've got going on. I'm trying to find, where's the deployment that? There we go, kind deployment. So above that, we can see there's a service and another service. So each one of the components is going to have that. And then we're going to have a deployment for each one of our deployments or our components. So we've got the admission controller. Yep, the admission controller, there's the pod name. It's going to run Keverno v1.11.1 from GitHub Container Registry, bunch of different options that we're going to apply there. Okay, so this is quite an extensive file. We're looking at, yeah, let's go to the very bottom. We've got 45,878 lines of YAML. So there's a lot of things in here. If you're going to adopt this, I would definitely recommend getting more familiar with all the components and we'll take a look at them once we install this beast into the cluster. Okay, so we're going to run their install, right? So we're going to do kubectl create now. And we can see all of those things that we would just walk through. There are all the service accounts, there are all the cluster, custom resources, a lot of cluster roles and a lot of our back stuff being created here, because this is going to need to do a lot of things in the cluster. So it's going to need quite a few roles and role bindings. We see a service that gets created for the components we've got that we saw in the ML as well. And a couple of crown job things are going to run behind the scenes as our cleanup pieces and the things that are looking at things outside of the admission context. Okay, so now that we've done that, let's, we can verify we got that new namespace here. So we've got our key for no namespace. So I am going to change my namespace to use that by default for now. Okay, and inside of this namespace now, I do kubectl get pods. We can see that we've got our admission controller running, the background controller running, the cleanup controller running and the reports controller running, that's great. Let's just look at everything that's in here using the kubectl get all command. So we see the pods, we see the services that were created. This didn't create like an ingress. These are all cluster IP things. So this isn't directly exposed to the internet, which is probably a good idea. We've got our deployments. So the admission controller, the background controller, cleanup controller and the reports controller, the replicas that are controlling that and then our crown jobs with the associated schedule. So this is going to run every really bad at crown scheduling. I always have to look it up and see what that is. Crown job schedule, Kubernetes. Oops, making my window a little bit bigger. Okay, so let's get started with crown jobs here. What's a crown job? So the schedule or the pattern here is minutes, hours, day, month, day of the week. Okay, so we've got star slash 10. So this is going to be in the minutes. See if we're are 15 here. Yep, this kind of job can also be scheduled to run at a specific interval using the operator. For example, the following the slash operator. So this crown job will execute every 15 minutes. This one's going to run every 10 minutes for us. So this job is going to be running behind the scenes every 10 minutes and doing the cleanup of things for us. Okay, so cool. We've got that installed now. Let's go back to our quick start docs and see what we're going to do next. Okay, so in the validation guide, we're going to see how to use Keyverno as a validating piece. We want to ensure that the label team is present on every pod that gets created in the cluster. This is going to be, we've done, I did the things like this in my previous job using OPA. It's a pretty common pattern, especially when you're running like a multi-tenant cluster and you want to be able to do different things and different namespaces and automatically enforce some of those things as they're coming in, right? This is a pretty common use case. So it's really nice to see that that's here. We want to require that labels here. So this is a little different than what we saw in the first example we looked at with adding the labels. Here we're going to do a validation. This is not going to mutate things for us. This is just going to validate that the thing that's coming in has what we want. So again, this is going to match any resource of kind pod. So any pod that comes in is going to need to have the metadata label team with some value there. And if it doesn't, it looks like you're able to specify a message here, right? So let's do this. We're going to drop this over into our terminal window. So we're going to kubectl create with this stuff as an in-place file. We're on that. And there we go. We have our require labels policy. So now if we went to look cluster policy, we have our require labels piece. It's kind of cool. There's a validate action here. So I assume this would allow us to turn this off, turn it back on, maybe just warn on some of those things. We'll take a look at that next. Hopefully that comes up in the guy if we jump over to that. But if we get the YAML for this, it's going to look exactly like what we just did. Cluster policy, require labels. So there's our thing. So we can come back and edit this too, I think. One of the cool things that I see here is that we're going to see how many rules are inside of this that have been created. And I would guess that we're also going to see maybe some information about when this applies. So let's go on to this next step. So we're going to just deploy Nginx into the cluster. So we're just going to YOLO this Nginx image into the cluster and see what happens with that policy. So let's do that. So again, we're just going to do a QTTL create a deployment type, we call it Nginx and the image is Nginx. So there's no labels applied to this, right? This is going to be a very basic thing that's coming in. Kubernetes is going to default all the rest of the things and there will be no labels. So we would expect that Keverno is going to reject that for us. So let's take a look. Nope, it did not do that. So you should see this error.  I just created it inside of this namespace. Let's go back and do it in the default namespace and see if that makes a difference. QTTL, delete, deployment, Nginx, oops, Nginx. Okay, so I think we probably also want to do this in the default namespace just to make it clear. So we're going to QTTL, delete, cluster policy, policy, can't type today, require labels. Okay, cool. So now we should be back to our state. Yep, that looks right. There's no deployment for that thing. And I think we should have no cluster policies. Okay, so now I'm going to switch back to the default namespace and try that out. That doesn't work. Then we'll debug Keverno and see what's happening with the initial controller piece. Okay, so back to here again. We're going to create this policy one more time in the default namespace. Okay, so now get cluster policies. Yep, there's our cluster policy. It's ready to go. And now if we do this, hopefully we see that error. Yeah, okay, cool. So I think what I saw in this down here was that it is configured to exclude the cube system in Keverno namespace. So made a mistake by switching to that namespace and then doing everything inside of it because Keverno is ignoring that namespace. But that's great because that means you're able to configure Keverno to ignore certain things. You probably want to make it not do things to cube system because that's required for your cluster to run. Probably also don't want it to make changes to Keverno itself because it's going to be in your mission path and it's probably a bad idea. Any other namespaces that you probably want to not apply policies to, I think you'd be able to exclude them. We'll look at the config for that in just a second. Here we see exactly what the docs told us was going to happen, right? We were unable to create that deployment. So if we do a kubectl get deployments, that thing did not get created. So if we go back to our diagram real quick, our API request came in. Definitely I'm authorized to create that. We saw that in the first go-through where I tried to do it in the Keverno namespace. The policy we're doing right now is a validation, not a mutation. So it's going to skip this piece. It's going to go out a schema validation and make sure everything in the request is valid. It was a valid request. Kubernetes built the deployment for us with that command. And then it hit that validating admission piece and went through and the engine said, hey, you are in conflict with that policy. So we were not able to create that engine X deployment. And it was because of require labels. So it's cool. It's showing us exactly like what rule is responsible for that. And it's also showing where the validation kind of failed for that. So the label team is required. And you would look inside a spec template metadata label to find the team label. Okay. I would guess now they're going to have us created again with that label. Yep. So really easy to do this, right? We're going to just specify dash dash labels on the command. Okay. So here we go. We're going to do a kubectl run engine X, different little different command. We're doing run here instead of deployment or create deployment, but this is going to result in kind of the same thing. And specifically what's going to happen is the labels are going to contain team equals backend. Okay. So now our pod was created and now we do kubectl get pods. There's engine X. It's running kubectl get pod. Engine X. And let's just spit it out into YAML. If we go up to the top here, we'll see, yep, definitely we've got labels equals, all right, labels contains team backend. So any value of backend, of team would work there. We could run another one here. Let's delete the pod. Okay. We're going to run this again with just another value. We'll call it CLBO, we'll actually back off. And that went through just fine. Kind of curious if I could modify that policy and make it specifically require like a value for that label. So let's delete that. Let's delete the cluster policy and recreate it from up here. All right, so let's grab this again. And I want to change this wildcard down here to CLBO, oops. Okay, we're gonna hit enter now. Okay, so we've created that policy again. And up here in our rule, we've got team, so I think what will happen here is that the team has to be CLBO. So now let's try to recreate that pod again. And let's use that original one where we're gonna set this to backend. So my hope, if I'm understanding this correctly, is that this will fail that validation check. And sure enough, it did. I didn't change the error here. It needed to be a different message to make it clear, but it did fail if we wanted. So I think now if we do CLBO here, cool, it created it. So you're able to make basic changes like that to the policies and that's really great. Okay, so let's go back to our walkthrough and see what we're gonna do now. So this was compliant, we did that, made a little bit of a change and made that happen too. So now the pod exists, wait a few seconds longer and see what other actions it took. So we can run QCTL get policy report. Let's see what that looks like. Okay, so we've got a policy report engine next passed. I think that was the most recent one. If we do that again, let's do, let's change this to engine X2. Wait just a second, maybe it won't, maybe it won't. Okay, let's see. If you were to describe the policy above, you'd see more information about the policy and the resource. So let's see if it came through now. Nope, didn't, it's kind of interesting. If anybody has used Giverno and has experienced with those policy reports, feel free to chime in in the chat. I think it'd be interesting to know a little bit more about what gets created there. If you can explain anything that goes along with that. Okay, we're gonna describe the policy report. I think maybe I fell in the docks that it applied to successful admissions. So maybe the failure one doesn't show up because it wasn't successful because it was blocked. I would maybe think that that would show up in error or fail, but maybe this is because it's happening behind the scenes and not actually on the rule itself. Before we go on, I wanna do one more thing here. It keeps to get cluster policies. Okay, I want to get cluster policy require labels. Let's get the ML version. Okay, nothing shows up in the conditions or the status I think for what's happening here. It'd be kind of cool to see everything that's happened for this rule, but they would get messy and a lot of updates to the objects, so that makes sense. Okay, so we have successfully validated our first object so we can delete that policy now. Let's do that. Looks like next we're gonna try out mutation. Really excited to see that. Okay, so same kind of policy here. In this case, we are going to add a label. So similar to what we saw in that very first example, here we're going to add the label team with the value Bravo. So this will add the label team to any pod and give it the value Bravo, but only if a pod doesn't have this label assigned. Oh, so that's cool. So you could probably replace this piece with just team and it would automatically add that, but this plus notation is allowing us to define what should happen. This is that FN kind of logic that's baked into that. So that's kind of cool. Let's do that. Okay, so there is our policy created and now we will run Redis. Oh, that's exciting. So I'm gonna run Redis. Okay, our pod is created. Hello, Daniel in the chat. Okay, so we've got our pod Redis now. So if we do cubes CTL describe pod Redis. Yep, it's created. That's cool. And then, oh, hey, labels. We see team equals Bravo. So that's the mutating policy at play for us. Yeah, we could do this command too, I guess, but that's what I wanted to see. Okay, so we've got team equals Bravo. So this next example looks like it's gonna show us how to do, how that like conditional logic works. So we've got that plus team here. So if we specify a team already, it won't modify that for us. So let's do that. Back to the other window. Okay, so we're gonna do, oops, sorry, clear. We're gonna do cubes CTL, new Redis, image Redis, and then apply that label alpha. Okay, so that's created. And if we were to do the same command here, there's our new Redis with team equals alpha. So it didn't append team Bravo to it for us. That's super cool. That's a really nice functionality to be able to encode that. I don't think I would know what that meant without reading that piece of documentation up here, but I think that's pretty small hill to have to climb in terms of kind of understanding new syntax. Okay, so let's delete that one and move on to the next one. I think today we're probably only gonna get through this basic set of like what functionality is there. I do wanna go look at the image stuff in just a second. I think we will do another episode of this where we'll dive into a little bit more depth. There's a lot of content to kind of get through in this project that I really wanna see with everybody. Okay, so we've deleted that policy. So now we have no policies right now. We're back to our kind of clean unrestricted state. Okay, so now we're going to create a Kubernetes secret that will simulate a real image full secret. So let's do that. Okay, so we've got our image full secret created. Okay, next we are going to create a generate policy. So this looks a lot like the other policy resources, anything in the resource of the name kind. We're gonna sync image full secrets. So this sounds pretty cool. It has the ability to synchronize the resources that it's generated. That's really cool. So it's gonna watch those things and figure out what to do. We are gonna use Kieferno to generate an image pull secret in a new namespace. That's really cool. So you wanna apply defaults to a new namespace, especially in cases like where you're doing a multi-tenant cluster as a service for folks. This would be super, super useful to automatically populate it with some certain pieces of information that need to go along with that. Okay, so let's do this real quick. Okay, so we are going to create this new cluster policy called sync images. It's gonna apply to namespaces and it's going to generate a new secret named reg cred and whatever the request object is.  That's what would get populated here and the action that it's gonna take is cloning from the default namespace red cred. Okay, so let's do that. Okay, secrets created, the policies created. So again, Qubectl get cluster policies. Cool, they're sync secrets. So now let's do Qubectl create namespace crash loop back off. Qubectl create namespace crash loop back off. Okay, so our namespace is created. Good to go, can do Qubectl get namespaces and hey, we see our new crash loop back off namespace. So now, if we do Qubectl get secrets in crash loop back off, there is the reg cred one that got created by Qubectl, no, that's really cool. So if I do a Qubectl get secret reg cred in CLPO and let's get it as YAML so we can read it. We see a bunch of labels that were created on this for like from Qiverno, right? So here's the secret piece, that's what we created before, but this is all really, really cool. So this is managed by Qiverno. We see some information like where it came from, came from the default namespace and the source kind was a secret, the version of this thing. So if we modified that Docker config secret, I think it would probably regenerate this. I don't think I've seen that in Gatekeeper or in Opa. I haven't looked into the documentation super deeply, but that's a really cool piece of functionality, at least in my opinion, I think if I was building a platform for my internal developers to use, that would be a really, really powerful way for me to control and kind of help maintain the contents of what's gonna be inside of that. Okay, so we went through a little bit about the introduction piece. I would definitely recommend taking a look at this. If you're playing along at home, definitely, or in the office, if you're working from an office, definitely go through this and give it a try. I think this is a really good taster of what the functionality is there. I am interested in a few other things though. So let's go to the documentation. I'm gonna jump away from the introduction for a second. And I wanna see if we can find the image validation stuff. I don't know if that's gonna be under here, under security. If anybody has used Keyverno and knows the docs, I'm really, really interested in, okay, let's go back here. The verify image piece. So maybe it'd be under sample policies. You can see them there. Yeah, okay, so let's look at the sample policies for verify image. So there's a few different things that I see here, right off the top of my head that look really cool. So we have one here for requiring image vulnerability scans. Let's open that up real quick. I'm gonna take a look at that. Yep, so I mentioned cosine earlier, verify image with cosine, verify that there is a cyclone DXS bomb for that. So a software build materials. A lot of places are doing that now to comply with the executive order from the US government, but also just in general, to have a little bit more awareness about what is in the software they're consuming, starting to demand those things, and also generating them themselves. Also verify salsa providence. So this is a really cool standard for describing how a build happens, and including metadata about the build. So you have more visibility, more transparency into that build process. So that's cool. So let's take a look at those. I wanna see this image vulnerability scan piece first. So we've got a policy, you see that here, right? And it looks like it's gonna match pods, and it's going to verify images in a repo. Okay, so I can specify multiple repos there. And we can look for different attestations for those vulnerabilities. This is gonna use a six door to do, to attach the attestations to the image. So they're kind of like a connected object, not in the image itself, but another piece of metadata that's associated with that. So that's really cool. This policy ensures that images signed with cosine's keyless ability during a GitHub actions workflow have attested vulnerability scans not older than the week. So this is checking to make sure, oh, so that's what this predicate up here is. It's checking to make sure that if the image has a keyless signature from my repo, and the issuer is GitHub, that's how signatures are created inside of with cosine and the whole six door flow. It'll validate that against recore, which is their transparency log. It's just gonna say like, at this time, this thing was signed by that workflow to validate it. And then it's going to check the conditions that it has a scan finished on date, less than or equal to 168 hours. That's pretty powerful. I don't have time to dig into this one right now, but I am definitely gonna include that for round two of this, because that's a really cool capability.  That's a really nice feature to be able to do at your cluster. If you're not running any of this today, that's a really cool thing to take a look at. I think this is another one. We're starting to see this a lot more. Kubernetes images, for example, are signed with Cosine. We do that as part of the release process today, and there are signatures for those images. So you could write a policy in your cluster that says that all of the Kubernetes pieces, you're probably not gonna do that because we're excluding our cube system where some of those are gonna run. But think about the same kind of policy for images coming from your internal dev teams or from EKS, maybe they're signing them that way as well. And what this is gonna do is allow us to do a couple of things that I see right off the back here too. Is this gonna mutate the digest? So if you make a request to your cluster or to deploy something with say Nginx V130.0, if that's the thing that exists today, I think this is gonna mutate it and set it to the digest because that's an immutable reference, that V1.30.0, that can change over time. So when this is coming through, this is gonna attest that this thing was signed to verify images with this public key, which is gonna be your signature piece. I think you could also do this with a keyless route. So we're gonna dive into these things more in the next episode of this, but this is really cool. So from the Keyverno repo in GitHub Container Registry, anything that's test verify image, we wanna apply that verification too. So you could do this and not require it for all things. That's a pretty powerful ability to do that. Yeah, I'm really excited to try this out next time. But let's take a look at what other things are in this policy category for things we might wanna look at next time. Anybody in the chat, in the couple minutes we got left, if there's anything in particular that you wanna look at, feel free to give me a shout out. PSP migration is a cool one to look at. Let's take a look at that. So PSP migration is a thing that I think, if you have been running Kubernetes clusters for a while, you've probably dealt with. PSP stands for Pod Security Policy, and we see that here. Pod Security Policy was deprecated and it's been replaced with a new Pod Security Admission Standard. And this looks like it would allow you to take care of some of that migration, some of that conversion for you. And this one looks like it runs in audit mode by default instead of enforce. So that's another thing we didn't really get to take a look at, but if we go back to our, let's create that policy again and see what it shows us. Okay, here's our validation policy back here. Okay, so a label is required. So if we do kubectl, get cluster policies again, we see that that sync secrets one is running in audit mode. So it's not gonna enforce anything on admission, but the required labels one is set to enforce. So that's what we saw, this one blocking things. We could probably change that to audit instead. I think that's a really cool functionality. So you could run these things for a while and allow people to come in and kind of gather audit information about who's in compliance and who's not with the things you rolled out and then enforce it without having to break people right away. So that's a really cool functionality here as well. I see a couple of familiar things like Valero. So we've got some things for backing up volumes. That's kind of cool. Let's take a look at the AWS policies and require encryption with AWS load balancers. That's a cool one. Best practices, let's see. Oh, that's nice. Check for deprecated APIs. Again, if you've been running Kubernetes clusters for any amount of time, you've probably dealt with the deprecated APIs. It's not as bad as it was. I think we have upstream, we have done some things like making beta APIs not enabled by default. So there's some less likely foot guns to happen, but this is a really nice one to have so that you can apply different rule sets to see what's going to happen and run this probably in audit or block mode. I think you could phase that in and have it run in audit mode, get an idea of what things are going to be removed and then have it run in block mode so that it can kick some of those things out. That's pretty cool. Down here, there's a list of in the two minutes we've got left for this one. We can see the different type of objects that you can create rules against and or whether there are some existing policies for it. There's a really extensive set of things here. So if you're going to look at Keyverno, I would definitely recommend coming to look at these sample policies or this policy library, I guess, because there's just so many things inside of here that will probably give you some capabilities to go with, right? Adding the time to live to jobs or restricting jobs, that's a really, really useful thing to do. Apply limit ranges, that's another really good one. Enforcing quota and things like that. That's a really great use case for mutating, right? Like you're trying to better manage the resources in your cluster and folks are not applying limits and requests to their workloads. You could totally use an admission controller, like a mutating thing like this to go in.  Okay, so just kind of wrap things up. What we saw today was how to install Keyverno in a real basic way. I don't think that's probably the right way from a long-term perspective. You know, under installation, there's a bunch more documentation that you can see here on how to install it, different installation methods. There's a helm chart if you wanna use helm, if you're using helm. If you are using customized, like you can grab the ammo like we did and apply whatever changes you want to it. That's really, really cool. We didn't take a look at testing things or actually writing our own policies, so maybe next time we'll do that. But we did see some basics on what the policies look like. We saw some validation and some mutating policies. So I think we got the basics here. We kind of know what Keyverno is doing, what it's all about. So join me next time and we're gonna dive into a little bit more about how to write our own policies and deep dive into a little bit more about some of that image verification, some of the supply chain security stuff because I'm a little bit close to my heart right now. Thanks for joining me today. I'm happy that you were able to join us and thanks for learning about Keyverno with me. See you next time.


Hello everyone, welcome to another Narc Survival Live video and in this video we're going to be talking about how they feel when you go no contact because many people think that narcissists have no feelings as though they don't feel anything but they can actually be far more sensitive than a normal person they are hyper sensitive hyper reactive so when you do something an action they are going to have a reaction whether you see it or not whether you know it or not they are they are not completely dead inside they do feel so yes when you go no contact they will feel something and in this video we're going to get into exactly what that something is when you go no contact it makes them wonder why but they are very arrogant and delusional they have magical thinking so sometimes they think that you're just playing a game because they're playing a game with you so they assume that you're just doing the same thing so initially they may not take it seriously they may think that it's just an act because they're putting on an act with you and they may think that you're not really about it as though you're not really meaning what you're saying and what you're doing but the longer that you stay no contact you go from seeing it as a game to then feeling that rejection to then feeling that sense of loss they feel like they have lost something and they become jealous they assume that someone must have taken you away from them because in their minds they've got you wrapped around their thumb they've got you under their spell they pulled the wool over your eyes so there's no way that you could have figured it out on your own someone must have come and taken you away is what they're thinking so they feel a sense of loss and they feel like they're missing out on something because as we know that is one of the main causes of their suffering is that they're missing out on something and that is especially what they feel when you go no contact because they sense your energy slipping away and the longer that you persist with the no contact they will begin to feel it even more in the beginning they may just see it as a game they may not take it seriously and they may just play that game back with you they will go no contact with you too they may even block you because in the beginning they're just seeing it as a game they don't think that you're really serious about it but if you persist with it they will begin to feel that sense of loss they will begin to feel like they're missing out on what they used to have with you but I don't mean they cherish the memories and the good times no of course not they never cared about that they never saw any sentimental value with you it was all about what they could get from you that was their only concern is what you were going to give to them how they were going to benefit from it how you were going to make their lives more convenient it was never really about you it was all about them and when you realise that the easier it will be for you to break away and for you to move on with what you're trying to accomplish what you're trying to build but yeah just know just know that when you go no contact they will feel it they will sense it and don't be surprised if they try to get you back they may try a few hoovers and if that doesn't work if they can't pull you back in if they can't get you under their spell again then it will make them very angry and yeah they may rage at you they may bring their flying monkeys and start a smear campaign they may stalk and harass you they'll do whatever it takes to get under your skin to get your attention to get you to notice them because now you've taken your attention away from them and put it back in yourself and now you're living your life again the way that you want to the way that you choose to instead of being under their control and that is what they don't like because they wanted to control and dominate you and tell you what to do and tell you what is right and your freedom is really the number one threat to them because all they really want is power and control and when you go no contact you take that power and control away from them because you stop giving your power to them the power for them to make the choices and decisions for you so again to advise it go no contact you don't have to block them but just don't look at the social media don't respond to the text messages don't ask the phone calls just leave it alone and just focus on you focus on doing what you want to do focus on yourself, care yourself, love working yourself do what you want to do now and just live your best life become the best version of yourself and don't let them hold you back don't let them distract you you just keep doing you as you can see I'm out here by the fountains and I'm living my best life as I do every day as I have been doing every day for the past four and a half years and I am loving every minute of it and I want you to do the same thing it all starts with the belief you have to have that belief in yourself and then you can do anything you can be anything you want to be you can do anything you want to do it all starts with that belief and that's why I'm out here putting these videos out every day because I want to instill that belief in you when you have that belief within yourself it compels you to take action and then you will find bigger and better things and you will wonder what you are doing with that and that's what I want for you to move on to something better and I don't mean another person I mean a better version of you and you can do it let me be your motivation let me give you the determination that you need that's why I'm putting these videos out every day alright so as always thank you all for joining me 72 live viewers please give this video a thumbs up down below and share your thoughts on the comment section I'd love to hear from you I read your comments every morning hit that subscribe button to receive notifications for my future videos and if you are interested in a one on one coaching session with me go to my website it's NARC Survival.co.uk and you can also follow me on Instagram I've got new pictures and videos every day it's NARC Survival YouTube and Instagram alright thank you all for joining me thank you for your support and I look forward to talking with you in another video very soon


Rwy'n ei gondol, rydych chi'n deillio i gael eu fathol, roedd y cwm yn cael eu hwnnw i ddefnyddio'r ddodol ac yn ei ddysgu o'r cwestiynau of the quantified self, I mean, some of the issues we looked at were actually philosophical questions, phenomenological questions, others were actually political and economic and social and so on, and that in itself, it does actually reflect how practices of the quantified self and practices of self-tracking are becoming more and more ubiquitous, and hence why we need to actually account for the different and multifaceted nature of those practices, and as you remember we began by talking about the kind of relationship that we are actually developing with our technologies and with our self-tracking kind of practices, the forms of kinship and the forms of relationalities that are emerging out of this coexistence of users and the technological, and personally that actually brought to my mind some of the very kind of early high-degurian arguments about the being with technology, the kind of the dasal and metzain with technology through which, I mean, through this argument high-degur was trying to kind of deconstruct the idea of what technology is in the first place beyond the dual tropes of the instrumentalist view as well as the anthropological view, and I think that practices and technologies of the quantified self fall within this kind of like the being-with of technology because they're not just about the technological alone and neither are they about the human agency alone, but they embody a sense of co-creative, we mentioned co-creation here, co-existential and hybrid agency, so that's why it is important when we are analysing these practices and approaching them through our kind of critical lens we have to account for this hybridity that is inherent within these practices, and then we moved on to talk about the issues of quantified practices within the workplace and how increasingly employees are being kind of subjected to certain practices, but in a kind of willful and voluntary sense, not yet as Chris argued in an imperative or in position kind of perspective, but that is an interesting shift because increasingly we are seeing how this kind of this this ideology of improvement and tracking and self-betterment is seeping into other spheres, not just leisure or exercise or sport, but also the workplace which kind of blurs the boundaries between the sphere of privacy and the sphere of intimacy with spheres of labour and work and so on, so the question remains would these practices remain at the level of the optional or the voluntary or are we actually designing a future whereby we see these practices becoming the norm rather than the exception or rather than just a voluntary practice and then again when we are co-existing with technology and we are actually interacting with it and when these media technologies become embedded and into woven as Joab argued into our everyday cultures, into our own bodies themselves, this is bound to actually affect how we understand ourselves, how we understand our bodies, how we understand what it means to be healthy in our days in the first place and what it means to actually have a body in the world in a phenomenological existential sense, so that's why it is important to sustain that kind of interest and research into the effect of these technologies on our self-perception representations and performances within a different context and different spheres of life altogether and then also I liked how the notion of neoliberalism has been challenged, I think we really have to be cautious and I'm so glad to see that all of the panels have been cautious about it to turn neoliberalism into a catch-all phrase whereby anything is dumped into this black box of neoliberalism because certainly the quantified self doesn't actually carry within it practices that are very much entrepreneurial, very much neoliberal and kind of almost act as a mouthpiece of the ethos of neoliberalism but at the same time there are instances I mean for instance in Dorthys case where it is not so much about this entrepreneurial self-optimizing kind of strategies of selfhood but it goes beyond that, it embodies them but at the same time it challenges them, so looking at kind of this dialectic and this dual kind of understanding of these practices beyond neoliberalism is very important as well and then issues of privacy also I really enjoyed hearing that you know privacy is not really a neutral or static concept which is context independent but it is very much about the cultural setting, the cultural context and whenever we are arguing about the need for privacy or maybe the obsolescence of privacy one has to to be able to account for the kind of geographical, the social, the cultural, the economy context that come with these self-tracking practices and I think all of these issues that we have covered that's still the tip of the iceberg, there's so many things we could have covered but obviously it's one day events and we cannot actually cover everything but I'm very glad too that we have contributed to you know to this debate in a more kind of nuanced and critical sense because I think it is very important to like raise awareness that the quantified self-practices are not neutral practices they're not just about enjoyment or the pleasure of tracking and sharing data with each other but they do involve many many aspects that have far wider outreach and wider implications that people have to be aware of. So my own personal project here at IS is actually dealing with the quantified self-practices as well and I'm looking at it through both a philosophical as well as a sociological perspective and if you are interested in staying in touch and knowing more about the project and following its progress so here are my some of the details so we have we've just created a Twitter account for the project you have my email address and very soon we are currently developing a website and the name Metric Life so so I hope you stay in touch and thank you so much for joining us you've been a great audience and fantastic speakers thank you


Indeed. Why? Because it's self-preservation. If we as human beings throw those who are less fortunate than us under the bus, throw them to the wolves, then someone else is going to throw us to the wolves. If we help others along to come along with us, we are stronger than the people that want to throw us to the wolves, they'll have a harder time if we act as one. Extremely important.


Everybody forced here up in a box of 21 22 revolution basketball hobby for Joshua G Thanks, Joshua. Good luck Like does anyone have any more orders in queue Travis for clearly. Oh, don't see any more Is that what you're asking? Don't have any currently. No. All right. Let's see a galactic grove USF Nurkitsch Sugs base Astro Jason Tatum Shockwave Harden Yes, here's a sniff. It's kind of crazy. It's it's almost irrational if you ask me rookie astro miles of bride false inexplicable All these new customers In their first break mojo Astro Jeremy Grant Kaminga rookie revolution insert a cubic Dennis Schroeder numbered five out of fifty Wagner rookie base Luka lava two of ten as nasty Congrats Joshua There we go Joshua G with the Luka lava Love lava lava is In this product one of my favorite parallels across all products That we rip vortex Steph Curry Yeah, for the Dallas Marlins there Fracture drew holiday lift off Anthony Edwards and vortex. Yeah fractal Scotty Barnes Right around the third. All right There we go. Congrats Joshua. Thanks again. We'll get that right out to you


It was one of the most famous musical marriages in history, resulting in the sales of millions of records, breaking down racial barriers and winning over fans across the world. However, the one-time relationship of Tina Turner and her first husband, Ike Turner, was marked with violence and abuse. Before this tragic nearly 20-year relationship left Tina, who recently passed at the age of 83 physically, emotionally, and financially broken, the one-time couple owns a famous home in Los Angeles. Located in the View Park neighborhood, Tina and Ike's former residence was once a retro piece of history, but more recently, it was turned into a modern mid-century home. The Ranchdale property was built in 1956, featuring just under 3,000 square feet of space, and it was also used as Tina and Ike's home in the 1993 film What's Love Got to Do with It, about Tina's rise to fame and her tumultuous relationship with Ike. Before his death in 2007, it's said that the last place Ike Turner called home was his modest property in San Marcos, California, which is also where he passed away. The home, which Ike Turner once lived with his wife Tina Turner for over a decade, had quite the facelift in recent years, turning the 1956 built retro property into a modern mid-century residence. Located in the View Park neighborhood of Los Angeles, this ranch-style home span 2,964 square feet of space and came equipped with four bedrooms and five baths throughout. Not only was the home the actual place where Ike and Tina lived for many years, it also played the couple's home in the 1993 film What's Love Got to Do with It, about Tina's rise to fame, rocky, personal life. While many facts in that movie were reportedly fake, at least the main filming location was true to reality. Ike purchased this property, situated on just under a quarter of an acre of land in 1964, after he got a 40K bonus for signing a contract with Sue Records. Reports claim that Ike spent $100,000 for the residence back then, while in today's day, that would equate to nearly $900,000. The couple called this View Park property home until Tina moved out after leaving Ike in 1976, when Ike then sold it, fully furnished the next year for 115K. Those buyers kept the home, even with the super retro decorations for almost four decades and changed basically nothing about the pad. So when it came time to shoot the film, this house was an easy pick to make use of. Both the inside and outside of the house was featured plenty throughout the movie. Apparently, it was Ike's idea on how to design these retro and interesting interiors as he redecorated in 1970 while Tina was in the hospital. It was written in a biography about her life. When she was finally released, she went home to a real shocker. Instead of having spent money on flowers to send to Tina, she found that he had spent a small fortune on completely redecorating their house from floor to ceiling, in superfly, ghetto, or house chic style. Ike added a wet bar with a built-in fish tank, mirrored ceilings, a coffee table shaped like a guitar, and a blue velvet couch with arms that turned into octopus tentacles, if you could believe it. In the living room, he also had a Florida ceiling rock waterfall installed in the corner. Some features of the home remain to this day, but not those ones, including the ornate front doors that were actually custom made for Tina with door handles shaped like arms and hands in a Buddhist style. Another thing that actually stayed from Ike and Tina's days of living here was also the fieldstone fireplace and entry wall. While many of these strange home amenities could be seen in the 1993 film, one thing that was fake was Ike's at-home recording studio because in reality, he rented a studio in a private apartment, not on the premises. One thing that certainly was revamped was the formerly not-so-pretty kitchen. Tina hasn't quoted saying about this one-time green-colored cooking space. Ike thought I'd be happy because yeah, I did like green, but not necessarily in my kitchen. In that way, everything had been done first class, custom-made at the house. I mean, it cost a fortune, but it was poor taste. Well, the late Tina would be happy to see that the kitchen was completely refreshed and after renovations, all the cabinets and appliances were traded in for white and stainless steel amenities. The small doorway that opened to the living room was also fully opened up to give the area an airy and spacious feel. Out back, the pool area of the home remains largely the same and aside from the custom swimming pool, there's also a cabana and fire pit lounge area on the property. As shown in what's love got to do with it, Tina's time living here with Ike wasn't what you call bliss. She spoke about the abuse she endured at this property and elsewhere on many occasions, one time saying in 1981, my ex-husband was a physically violent man. I went through basic torture. I was living a life of death. I didn't exist, but I survived it and when I walked out, I walked and I didn't look back. And after she ditched Ike for good, Tina did find her own power and happiness, going on to win a ton of awards and record hit songs, as well as finding love again with her next husband, Irwin Mock. As for this property, following the huge remodel, it last sold in 2018 for just under $1.4 million. Looking back on what happened to finally end the cycle between Ike and Tina Turner, the moment she left wasn't until 1976, when the star escaped her abusive husband, it had been building up for years and Ike, the musician and band leader, had built an act around his wife. In his mind, he was the one who made Tina a star. The control that Ike had over Tina's life was immense and made it nearly impossible for her to prepare her exit, meaning when she did leave, she only had 36 cents and one credit card in her pocket. When Ike and Tina met in 1957, she was still an amade block, a 16-year-old country girl from a small town in Tennessee, while Ike was in his mid-20s and already published band leader and rising star. Tina impressed him enough with her unique singing voice that he added her to his band as Little Anne. There was no romance between the two in the first few years, and instead, Tina was in a relationship with the band's saxophone player and fell pregnant with his child, giving birth to her first son in 1958, just after graduating high school. Eventually, Ike would reorganize the band around Tina and in 1960, he renamed them the Ike and Tina Turner Review, while they had already started a romantic relationship. They even had a son together that same year, but they weren't legally married until a quick Tijuana wedding in 1962. Tina later said, I knew that I didn't want to marry him, didn't want to be a part of his life, didn't want to be another of the 500 women he had around him by then, but I was, well, I was scared and by now, this was my life. Where else could I go? We're a decade. Tina Turner lived a life that was a whirlwind of fame, her forming, abuse and drug use, which all centered around Ike, where on stage, she was full of energy, sexy and strong, offstage. She was an exhausted mom struggling to control Ike's rages and meet his demands. Years after, Ike would deny the extent of the abuse to Tina, stating, sure, I slapped Tina. We had fights and there had been times when I punched her without thinking, but I never beat her. In 1972, a few things happened that got Tina on her way out. She talked back to Ike for the first time and by then, she was raising the kids, writing the songs and paying the bills. She also found Buddhism and began chanting a mantra regularly. The more she chanted, the more she noticed her life improving. Tina was offered an acting role in the rock musical Tommy and filmed a TV special with Anne Margaret. Being on set, gave her a time away from Ike in a peek at how capable she really could be without him. Finally on July 1st, 1976, Tina saw her chance on a flight to Dallas to begin their next tour. The two began to fight and in the car on the way to their Hilton Hotel, Ike began slapping her. She remembered later, she hid him back, kicked and cursed, which is when she admitted she knew she was gone. As she freed herself from an abusive relationship, the planned review tour Tina had coming up failed and the promoters and advertisers wanted her to pay. She began booking appearances on game shows such as Hollywood Squares, anything that would generate cash flow and Ike wasn't giving an inch in divorce proceedings because he had copyrighted her name, he wanted to take that too. Eventually, she decided against her lawyer's advice to let him have just about everything, the house, cars, the recording studio, in exchange for her professional name, Tina Turner. The divorce was finalized in 1978. Tina had no many, no bands and no record label and she didn't know that it would be six years before she would release the album, Private Dancer, the biggest hit of her career. In her future also lay a happy marriage, Grammy Awards and induction into the Rock and Roll Hall of Fame as a solo artist and much more. But Tina had already proved to herself that Ike hadn't made her a star and whatever lay ahead, they would be her best days. While we know that Tina Turner went on to have the best days of her career after leaving Ike before her 2023 passing at age 83, what became of her ex-husband? Reportedly, the final home of Ike Turner was located in San Marcos, California, where he also died. There aren't many photos online of Ike Turner's home aside from aerial and exterior shots, but what we do know about the residence is that it spanned a modest 1,604 square feet of space and featured three bedrooms and two bathrooms throughout. He passed away in this North County home in 2007 when he was 76. While Ike was once a groundbreaking guitarist pianist, his reputation was tarnished by his drug addiction, stint in prison and of course, because of the abuse he inflicted on his ex-wife Tina. The cause of Ike's death hadn't been determined, but foul play wasn't suspected. Ike Turner's ex-wife and manager, Ann Thomas, was the last to see him alive in his bedroom just after 8 a.m. the day he passed. With the band members in the house ready to play some music to cheer him up, she delivered the news that he wasn't breathing. Band members tried unsuccessfully to revive him before paramedics arrived. Either way, Ike Turner's action in his marriage to Tina Turner resulted in the downfall of his reputation. Well, that story of the two late musicians in one time couple is a long and complicated one to tell. For today, that will bring this house tour to a close. Before we go, answer this question for me. If you bought a retro Hollywood home like Tina and Ike Turner's former spot, what's one strange amenity you might keep? I might have chosen the wet bar with built-in fish tank, but let me know your choice in the comments below. Don't forget to like, subscribe, and follow me on Instagram to chat. I'm Kari the Vampire Slayer, and if you'd like to check out more homes before you go, then stay tuned, because next we'll look at the properties of someone with a more positive legacy, Stevie Wonder. Bye. After making a successful career in music, Stevie Wonder has lived in plenty of beautiful homes from the East to the West Coast since his days growing up in Detroit. It's reported that these days, he and his wife live in the luxury Bell Aircrest neighborhood in Los Angeles, but he's also formerly lived in a Los Feliz mansion and one in Beverly Hills just to name a couple. Today, we'll take a look at a few of Stevie's homes we even found the listings. In these videos, we don't reveal any addresses, and even though I've done a house tour of my own place, please do not show up at any private residences because it's not safe for anyone. It's unlikely that you don't know who Stevie Wonder is as he's a music legend. The singer, songwriter, musician, and more was a well-known figure in music during the second half of the 20th century and one of the most successful. Stevie is essentially a one-man band and his use of electronic instruments in the 70s helped reshape R&B. He's been credited as a major influence to many musicians over the years of different genres from pop to gospel to rhythm and blues and more. Stevie was blind since shortly after birth and became a child prodigy known as Little Stevie Wonder signing to a record label at the young age of 11. In fact, one of his tunes was number one when he was only 13, making him the youngest ever to top the charts. His peak of success came in the 1970s and then he began a classic period with his music. Stevie has sold over 100 million records worldwide, making him one of the best-selling artists ever and has also won 22 Grammy Awards among plenty other awards and accolades. At the time of this recording, Stevie has amassed himself an estimated net worth about $110 million and has invested in lavish real estate throughout his life. His hometown is Detroit, Michigan, but these days he's made his main home in none other than Los Angeles. It's said he lives with his wife Tamika Robin Bracey in the exclusive Bell Aircrest neighborhood of L.A., where he's next door neighbors with Gordon Ramsay.  I noticed a bunch of you guys watching our videos aren't subscribed, so be sure to hit that subscribe button to ring that bell and help us get to a million subscribers. We post a new video daily. Today we're gonna take a look at where Stevie Wonder calls home, including a gorgeous mansion Los Feliz he used to live at and more. The icon has owned mansions from multiple properties in L.A. to Alpine, New Jersey, so it's clear he likes to invest in real estate. If you liked this video, we've reported on the homes of other music legends like Ray Charles and Prince, which we'll link to at the end. As always, don't forget to follow me over on Instagram to chat and now, let's get into this video. Like I mentioned, Stevie's hometown is Detroit, Michigan and when he was a child he lived on Hastings Street. These days, the house on the property has been described in listing materials as a charming ranch home and has been renovated and upgraded all around. This house sits on an acre of land and spans just over 1,000 square feet inside but it looks like a really nice family home. Then as a teen, Stevie was still living in Detroit this time in a Tudor style home on Green Lawn Street but this home has since been torn down. After Stevie found continued success in the music industry he eventually put down some roots in Los Angeles. He's owned multiple properties in the area and apparently still does including one in Woodland Hills, his current home and more. At one point, the musician lived in this beautiful Los Feliz mansion, which we'll take a look at. Back in 2008, Stevie decided to put this house on the market for $3.2 million and in more recent years, the gorgeous abode has gone up for sale again with a much steeper price tag of over $8 million. While Stevie purchased the home many, many years back from your 435K, he sold it for about $2.4 million. The home has been completely reimagined since considering Stevie bought it way back in the 70s and held onto it for about 30 years. It was in need of an upgrade. Situated on a lot spanning almost half an acre of land, the mansion is described as a 1928 Mediterranean house with an art deco period design. Located in Los Feliz, this neighborhood is a relaxed hillside enclave that borders Griffith Park and the Griffith Observatory. In recent years, the neighborhood has become trendier with both creative and famous people choosing to call Los Feliz home. Considering how desirable the area is and how the mansion looks now after being completely upgraded, it's no wonder the price tag jumped up by millions of dollars. Stevie's former mansion spans 4,511 square feet inside with seven beds, seven baths, and 14 rooms in total, including a beautiful pool house out back. Nearly everything was changed inside this house. They said goodbye to features like a tiki bar replacing it with a fancier marble bar. The mansion is located behind large wooden gates for privacy and it overlooks downtown LA right to beautiful ocean views. Walking into the villa, there's a dramatic double staircase and a rotunda-style entry with sparkling chandelier overhead and skylights. The hardwood floors below also lead down a few steps to a common space with wall of windows and a cute European-style terrace. A living room here has arched glass doors, vaulted wooden ceilings, and a fireplace. There are multi-level terraces across the mansion and most common spaces have doors to these spaces. Stevie's former mansion has been transformed to include a massive kitchen with all the newest and priciest appliances, including a huge fridge, and there's also a casual eating space with more doors out to a covered terrace. On the lower level of the home, there's a solarium-style room that's all walls of windows which has a lounge space and bar and walks out to the backyard. Additional features in Stevie's former mansion include a basement floor that listing materials claim was turned into a theater room. There is also a separate guest house cabana with its own bedroom and bath. Outside, of course, there's a luxury sparkling pool and spa set within a grassy lawn surrounded by patios. Just last year, another home that Stevie used to live at came up on the market, this time located in the coveted Truesdale Estates neighborhood. Stevie lived here from 2011 to 2015, but it's said that he was leasing the home instead of owning it, and most recently, this pad sold for a whopping $10.5 million. This shouldn't come as a surprise though, considering the average home price in this posh neighborhood is over $11 million. Truesdale Estates is located in the foothills of the Santa Monica Mountains and home to a long list of high-profile celebrities from Eva Longoria to Elton John and many more. The community was developed in the 1950s and 60s and is a highly private part of Beverly Hills. Stevie's former home here was set high up on a lot overlooking views of the hills and city lights and the Hollywood Regency style abode was a single level. Still, interior spaces spanned over 6,200 square feet, offering up four beds and eight baths throughout. The entire home, or most of it, boasted expanses of windows, especially along the back, that offered views towards Century City, while on a clear day, you can even see the ocean. The secure and gated grounds span half an acre of land and there's plenty of patio space and areas to dine and entertain here. Not to mention, there's the requisite swimming pool which also offers amazing views. Other features include a four-car underground garage which is accessed through the front entry. Four was listed in 2020, Stevie's former home was up on the market in 2006 for $4.9 million and last sold in 2015 for $6.4 million. A fair amount less than it's worth now. In terms of being up for rent, the property was priced as high as 21K per month in 2015, which would have been just after Stevie moved on from the place. My guess is that's around how much he was paying to live here. While we know that Stevie lived in and owned a handful of desirable properties in the Los Angeles area, like the two we just looked at, these days it's said he settled down in Bel Air Crest. While information on this home is kept really private, Stevie and his wife are reportedly next door neighbors to celebrity chef Gordon Ramsay here. Bel Air Crest is an exclusive 24-hour guard-gated community nestled in the Bel Air neighborhood of Los Angeles. It's described as a resort-style subdivision with about 200 homes or mansions, if you will, that have an average price of $10 million. Here properties boast views of the canyons and hills and luxury mansions are private and secure. The neighborhood is one of the most prestigious in the area, so it's no doubt that Stevie chose to call this place home. All right, so now we've taken a look at a couple of the homes Stevie Wonder has called home, so I think I'll wrap up this house tour here. After checking out two of his former properties, including the beautiful mansion in Los Feliz he sold in 2008 and his lavish Truesdale Estates rental, what did you guys think? I mean, we even saw his charming childhood home in Detroit, which you can compare to. Even that home, though it was modest in size, was charming. I absolutely loved the first mansion we looked at, especially how it was renovated in recent years. While this space is sprawling, there are still cozy rooms to make it feel like a home. I think my favorite parts of this mansion were the sunroom with walls of windows and, of course, the pool. Be sure to tell me what you liked or didn't like about Stevie's homes in the comments down below. If you haven't, go subscribe to my personal channel because I would love to get to know all of you better. We'll link you my latest video. Right on, right on, right. Oh my gosh. I'm gonna start talking about David Berkowitz. So, like I said, David Berkowitz. Thanks for tuning in. Don't forget to follow me on Instagram to chat and I will see you all in the next video. Bye.