Yes, hello and welcome. Thanks everybody for coming over from Christian Stream. Great job. Little get ops guy to the galaxy. Now we're gonna be talking security on Stack Rocks. Office hours, I'm joined by engineer at Stack Rocks, Connor Gorman.  Sure, yeah. Nice to meet everyone. I'm Connor. I've worked at Stack Rocks and now Red Hat for a little over four years. So kind of since the beginning of our current product cycle. And yeah, I'm a principal engineer at Red Hat and primarily working on the backend. So been around, been around for a while, been through the evolution of Kubernetes as well. And so excited to talk, you know, anything about security and containers and Kubernetes. Awesome. Yeah, for those who don't know Chris Short, obviously if you're watching the channel, Chris Short is gone last day earlier this week. So we're having a little bit of Chris Short woes. That being said, I'm Mike Foster standing in for him for Stack Rocks office hours. Couple announcements next, the following months, we're not gonna be doing the show on Thursday. It's gonna be on Tuesday, same time. And yeah, today we're gonna be discussing Kubernetes security, our top 10. Connor and I kind of put together a list of our top 10 things that I think people should be aware of, some mitigation issues in the Kubernetes that open source community that you can do. And then, you know, some more advanced features and more advanced solutions that you can look at as well. So with that being said, should we kick it off? Let's do it. All right. First one I think is a little bit of a layup, but we have Disabled Public Access as our number one sort of intro. I think it's kind of general, what do you think when you say Disabled Public Access, it's kind of Kubernetes private cluster, secure the API. Yeah, exactly. I think one of the main things from the API server perspective is that there's surface area there, right?  And so, you know, there's been a series of kind of attacks or DDoS attacks that happen against public API servers.  That's probably the least malicious way that they could use it. And then, you know, there was like the billion laughs of YAML DDoS that could occur. So, you know, those things happen, those things exist in the wild. And, you know, the Kubernetes security team does a really good job of triaging them and fixing them as fast as possible.  And, you know, that's a little bit of peace of mind.  And so that's always a good place to start from just air gap your environments a little bit. And some of the defaults that are installed in provider clusters, if you're unaware, might open you up to things like having, you know, it's like default Nginx backgrounds or stuff like that hanging around. If you're not sure, always good to keep it private before you really understand what's going on. Yeah, exactly. A lot of times, you know, you would just click a button and they're made to be super easy to use, right? Like, hey, give me a cluster of perfect and, you know, a lot of this, some of the security defaults are lost in that. And so, you know, you gotta be really careful about when you're actually building a production cluster because what you see a lot is that a cluster that you are playing around with doing a POC on or something like that starts running more and more critical workloads. And then over time now it's become a production cluster or a semi-production cluster. And so now you gotta like take a step back and make sure you're applying all the proper security controls. Yeah, those baselines aren't let's certainly properly there. It might work, but you really have an operationalized it. It actually leads into the next point, which is implementing the least permissive role-based access control. And I think we can kind of assume that everybody has our back set up in their clusters now. This wasn't really an assumption that we could make three years ago, but it's safe to say that now, right? Any thoughts on one, how to go about that, best practice, service accounts, things like that? Yeah, I think, like we just mentioned, sometimes your initial cluster makes it three years, right? And so let's make sure you understand kind of like, you do an audit of all your roles and role bindings and who's accessing your cluster. There's a couple of ways to do this. Within our product, we can show you basically all the access that you have. So you can look at a particular role and say, hey, are you a cluster owner? Do you have full access there? There's also a tool by Jordan Ligget wrote, which like will parse audit logs and it'll kind of tell you what people's access and what they've been using. And so there's some cool stuff out there to look at, parsing of audit logs and breaking that down. And so yeah, just make sure you're always auditing that. And then one of the best parts would be, start with minimal access and as people need it, slowly add it. And then of course, just the realities of running a production cluster is that sometimes you need to break glass permissions. And so building that process in where you have kind of an audit cycle of, okay, I need cluster admin for X, Y, Z. Okay, we got an approval or I write a reason why and that kind of like, then can give me the access I need, right? Because there are those scenarios where, DevOps folks or other engineers do need kind of more privileged access. And so always account for that. Otherwise there's going to be some service account sitting there that will grant that no matter what. Yeah. And reality is always somewhere in the middle. So instead of being most permissive and working down, least and work up, sort of making that a challenge. I think it's like a general theme with like Kubernetes and security, right? There's always this balance of, you have folks who like are managing the cluster, administrating the cluster, and then you have people running applications and there's going to be some level of debugging that you need to do on the cluster, right? And so how do you grant that access and how do you make sure that like, you're still providing the workflows of, actually running the applications first having a really hardened cluster? Completely agree, makes sense. And speaking of applications, container images. Now, not necessarily Kubernetes specific as the orchestration tool, but obviously our main workloads are running in containers. So managing vulnerabilities and providing a safe image. I assume when we talk about number three, we mean base image as well as your own application. So just thoughts on that. Yeah, so there's kind of been this concept for a while of also with even VMs, which is like the concept of like reverse uptime, right? Which is like you have an image and if you just leave it running for a really long time, something that I've always liked to say is that like the number of volumes in an image only ever increases because the image is immutable. And so, in your base distribution, there'll only be more things found over time, right? And so your image is naturally kind of drift towards less secure just based on the number of vulnerabilities found. And so constantly rebuilding your base images, all the distributions do a really nice job of constantly updating, fixing, critical vulnerabilities.  And then that can lead you to a much better place in terms of the vulnerability management within a particular image. You said something there. I think a lot of management teams don't like, but it's the vulnerabilities are never really going to go away, right? You're going to mitigate them and then over time they're going to creep back up and then you're going to mitigate them again. The challenge I think with vulnerabilities is finding that, you know, what are the things that we want to mitigate with containers, right? What are the most impactful things? It's like, how do you, how do secure teams make that decision? Yeah, I think you have to look at the, like Kubernetes gives you a lot of context about where things are running, how things are running, right? And so when you're looking at a vulnerability, many times there, a lot of them are not fixable and they can vary in criticality, but I always like to look at things that you can actually do, right? Like what can you actually fix? And so we've got a lot of fixable vulnerabilities with like new patch versions. You know, those are the no-brainers in my opinion, right? Like let's go rebuild those images, let's go redeploy them.  I know that's not always the case. And so you have to be cognizant of that, you know, and then constantly update those. And then also, if you can reduce the amount of packages you have, right? That just reduces your surface area.  And that just like provides, you know, kind of a slimmer workflow in case of vulnerability management. Yeah, and once those containers get into the cluster, Scott kind of moves into the fourth point. Managing secrets, environment variables, config maps, injecting various secrets and variables into your containers. What are your thoughts on securing that, the process for that? Because I always had an issue, especially once you get into teams, how do you manage secrets? How do you do it when there really was no encryption in Kubernetes, you know, three or four years ago at the beginning, right? It was, was it just base 64 there for a while? Yeah, exactly. So, I mean, going back to our RBAC point, that's like the first step, you know, if you're using Kubernetes secrets, the first and foremost thing to audit is who has access to actually reading or listing the secrets, they're the same thing.  You can encrypt them through like KMS and different methods. But, you know, when I, when I get a YAML of a secret, I'll be able to read the secret, right? And so, you know, who has the ability to do that? Some folks don't even let read, read for secrets ever happen. Like you can only write secrets.  This is a good workflow for like GitOps or different kind of like CD systems, like with the secret store, for example, which is a good example of that. But yeah, the secrets are one of the biggest challenges I think still kind of, that kind of exists within the ecosystem and there hasn't been like the perfect solution for any of that. So it's sort of an interesting area for sure. Yeah, and I know that I think if fig maps became immutable as well, there's the option for that aspect, which some people don't understand why can fig maps are immutable, but if you're injecting environment variables into your container, you kind of want, hey, we're gonna roll out the next version of this container, which should probably make sure our config map that's going to be used to set up this container is also versioned with it. Little things like that I found really interesting. Yeah, one thing I've seen is that it'll take some aspect of the config map and like hash it and then you put it as the label on a pod. So then like if the config map changes, like you can see which version of the config map should be running because they do hot swap it underneath the mount, right? So you can be running a container and the config map could change. And so you're kind of in this weird state where it takes about a minute to propagate and you're not sure, you know, which config map is there or does my service actually hot reload the configs in some ways just rolling out like doing a rollout of the pods would be an easier way to guarantee that, okay, this config map is gonna be mounted because when you roll out the new pod, you will always get the most recent config map attached. And so that's kind of a way that some people mitigate the kind of uncertainty of I modified if config map did my change actually propagate. Yeah, especially if you have any sort of CD process or anything like that with testing setup, you can always roll back, right? If you config map screws up so you're not sitting there in limbo. Yeah, exactly. That's sort of like a helm. I mean, that's like one of the benefits of something like helm, for example, like, you know, they're all in lockstep, you know, our operators in the OpenShift ecosystem, the similar concept, right? Like, you know exactly what you're getting all together at one time. So that's a big benefit of kind of like the bundled approach of deploying your service. Now, had number six, and by the way, anybody, people who are watching feel free to put your questions, comments, things that are bugging you about security.  I like to be wide open, that's fine too. But I'd love to hear your feedback as we get into number six, which I found is a sneaky security aspect that is overlooked, often overlooked as resource limits. Want to get your thoughts on that. So yeah, this is sort of like a little bit contentious too, actually. So resource limits from, you know, depending on what service you're running, yeah, really matter. So one aspect is that helps you provide the segmentation that you want between different services, right? You don't want one service to basically be poorly written or have a fork bomb or whatever, right? Like just suddenly fill up a node and then start having things be killed. I mean, the OOM process is fairly good. It will try to kill first the things that are over utilizing their resources and depict them. It's not a foolproof process by any means.  That puts some pressure back on the DevOps team and the team itself to optimize their code. So sometimes without that pressure of like you need to set resource limits and constraints, you know, there isn't as much reason to optimize your code for that reason, right?  It's kind of like up to the infrastructure team and that's a challenge for any infrastructure team. And another thing with resource limits and I think security and availability go hand in hand a lot, which is resource limits allow and having them be as low as possible help you schedule things in your cluster, right? And so, exactly. And so you can schedule things more readily if you have proper resource limits and constraints set. So those are some of the main benefits I see from a security perspective. Yeah, I think especially for stateful workloads, if you're setting very strict limits on and especially if you have a limit on your stateful workloads but not on your other ones, they get the default for the namespace but they also get evicted first because they don't have something that's supplied by the developer or the administrator there too, right? So there's a little bit of assumption there and there's some pretty cool features in Kubernetes where you can set it by namespace too. So as an administrator, you can kind of say, hey, you in this namespace, you're only allowed this much work within it. Yeah, it's definitely especially in multi-team clusters. I have seen, I'm curious what your thoughts, I've seen a lot of let's say micro sharding of clusters. I don't know if that's the correct term but a lot of people using K3s or smaller clusters and using a cluster per team. Any thoughts on how you would set up resource limits for that or like scaling of clusters? Just kind of curious what your thoughts are.  But actually from a security perspective, I do like the smaller clusters, though you have to mitigate the challenge of like, where are my clusters, right? Which is something that happens, you know, you have a hundred teams, now you have a hundred clusters. And so you're always trying to find that balance as an organization of like, how many clusters do you have versus like running one large cluster, right? There's always gonna be operational overhead, between of running a cluster and some costs there, but you can really get the natural segmentation that you're looking for between teams by just having separate clusters, right? You know, you know, team A isn't bleeding their service into team B because they're literally segmented, right? Yeah, and so. The challenge is setting that policy so the cluster comes preconfigured for that team, right, as they scale. Right, exactly. And like, you can allow each team to scale up their clusters, but you want to make sure that you have like unified tooling deployed in that cluster, right? And so that's kind of as an infrastructure side, if you want to go that way, you have to be able to say, you know, speaking from personal experience, like with ACS, it's like, you know, you want to make sure that you have our secured cluster components and every single cluster that you deploy, right?  And so when they launch a new cluster up to 300 or something clusters, right?  Yeah, so clusters that get set up, they don't fall through the cracks, right? You're using some sort of like ACM for overall policy. I thought one of the coolest things that I had seen was the, through ACM, let's say you want to set up a developer specific cluster. You know, you can have the sensor set up for ACS, but just there's no admission controller. So it's like, hey, developer started up a cluster. Okay, there it is. I can see what they're doing, but there's no enforcement. So things like that, you can kind of mitigate stuff before it gets too far, let's say. Yeah, exactly, and in that way too, you can see, oh, hey, this person created a load balancer in this cluster, right? And so we have a lot of insights into kind of the overall context of like what's going on in each cluster. And so you can see, oh, hey, they expose this service over the internet, like that's not within our security policy or we haven't verified that. It hasn't gone through a security review, right? And there's a lot of aspects like that where they make it really easy to use this stuff, expose it over the internet, make it publicly available. And maybe that's not exactly what you want. Maybe they didn't realize the risk in doing that, right? In terms of, hey, yeah, I was just testing this from my local laptop and making sure the proper security controls are there from each individual cluster and the services that are being publicly pushed. The worst situation is to have a prod service that you don't know about that's sitting out there on the internet. And good thing we kind of got into that clusters. Number seven, we have segregate sensitive workloads. So there's a couple of points here, I think. Yeah, we already talked about secrets a little bit, but implementing and monitoring traffic and setting baselines, separating through Kubernetes native tools like namespaces, right? I guess we'll start with that. Namespaces, properly setting them up proper defaults, thoughts on how to operationalize that specifically with Teams. Step one, don't use the default namespace. There's actually some admission controllers and stuff that you can use that will say, don't let anything be deployed into the default namespace. I think it's sort of like, it's just someone ran KubeCuttle and something showed up there is typically what happens. And so you really wanna make sure everyone's in a proper namespace. I mean, the namespaces are super useful for some of the reasons we already outlined around like resourcing, for example, and seeing kind of the resource assumption of an individual namespace, but also it's a really easy barrier to say, this teams should not be able to talk to this team, or also like if you have a multi-tenant environment with different customers, right? Okay, customer A should not be able to talk to customer B and how do I go verify that? And actually I might jump over to the demo real quick foster. Sure, let's bring it in, cool. Sure, so this is our network graph. We're showing live traffic between different namespaces, right? And so this is kind of what's pretty interesting. It's like you wanna create network policies that deny between namespaces, but there might be holes that you wanna poke for things like monitoring, right? Like if you have a Prometheus operator running in your cluster, you want the monitoring to happen against your services. And so what you really wanna do is break down and actually verify, even from an audit perspective, that customer A is not talking to customer B. So Stack Rocks should not be talking to any of these other backends that has nothing to do with them, right? And so this is just a visual verification at least that you can do that. And then there's a lot of capabilities within the product that I probably won't go into right now around simulating network policies. The YAMLs are pretty difficult to write sometimes. And so you really wanna look at them and say, okay, is this doing what I think it's doing? Is this actually gonna block an active flow, right? Is this something that's actually being used? For example, this sensor is in a remote cluster, so there is no centralized component here. And it's going, you can see it reaching out to Google here at the bottom. That's because the central is in a different GKE cluster, right? It's in a different cluster. So that's where that one is flowing to. And you can see like the egress for it is going to Google. So sometimes there are things that you miss or things you don't think about. You don't think about sensor reaching out externally if it's in a remote cluster. And this is just an easy way to like visually check that this is occurring. And then another really cool feature is to be able to look at the allowed connections, which kind of breaks down what things can talk to each other based on network policies, right? And so this will help show you- Because most of the time you're configuring network policies because you're trying to get your app up.  You're right, exactly. Like maybe you just said, oh, everything can talk to this. And depending on the service, you have different levels of connectivity and ingress or egress, right? So for example, this is our collector. This is an agent that runs on every node. It doesn't run a web server. It needs absolutely no ingress, right? So this is saying we'll allow zero ingress flows based on the network policy we wrote. And based on the overall environment, we have 16 egress flows that will be allowed. So a lot of these other namespaces have no network policies set up. And so they can speak to all of these different pods in our cluster. Very cool. Yeah, the visualization aspect of network policies, I don't think that could be understated. That's a huge time saver, not working through all those YAML files. And one of my favorite aspects of moving development to test clusters was to just basically flick on and off network policies. You have some sort of network test, put it in the test cluster, put a default deny on and see what happens or something like that, right? If you don't have anything in the dev cluster. All right, yeah. So it's awesome. Yeah, the flow is cool. Yeah, I think some of the aspects, things that I would do here is like, maybe you have a default template for a namespace and you say, okay, from, you know, the namespace of Prometheus operator will allow all connections, but then deny all the other ones, right? And then every namespace that you basically print will then have that default deny. And then, you know, you just, if you need to poke holes later or someone's got a real use case, right? You can evaluate those at the time. If you can start this way, this is definitely the way to go. Now it's very challenging if you've been using Kubernetes for two years and you're running a bunch of production services, how do you start applying this to a cluster that's already running without breaking a lot of things? And that's where looking at the active traffic and crafting network policies that, you know, align with that active traffic is really useful for folks who already have clusters up and running, but they haven't gotten to the network segmentation portion. Yeah, the observability without enforcement, especially as a security tool is extremely useful, right? You don't want to be shutting down anything that you haven't exactly verified as normal traffic. So very cool. Exactly, yeah. And when it comes to security in configuration, especially, I think it's always turn on violations, right? So like, first you get visibility into something like network traffic, then you can start sending violations about things that violate that network traffic, right? That happens over time. You know, we don't have the perfect view of the world. You know, you could run Postgres and we could look at all the processes that run, but then when someone runs a backup and maybe the back it's by exacting in and running some command, right?  We don't want to kill Postgres because of that, right? So you want to see that, you want to say, okay, highlight anything that's outside of that band. Oh, actually, yeah, this is the backup. Good thing we didn't turn on enforcement right away. And then once you're very certain that we've like seen everything that you're looking for, feel free to turn on enforcement or violations that go to a higher, even a higher notifier, right? Getting emailed about something is not like being paged at 2AM or something. And so you kind of have all of these different tiering of kind of how you work through a security program. Now when you're scheduling all these notifiers, how would you group them? Like does it get shot out by team administrator? Like let's say there's a network flow that violates some policy. You obviously don't want to blast it to everybody on Slack, right? For something like that. So. Right, exactly. Is there, on the platform, how would you manage something like that? Yeah, so you can annotate your pods with like specific aspects that you'd like to route through. So you can say, okay, to the Slack webhook or, and that would be done on a pod basis or a deployment basis. The same thing with like email, right? A lot of times people will have an owner field of like here, here's the team, you should email about some of these issues. And then of course you have, you know, levels of when you'd want to send these notifications and how serious and the relative severity of them, right? And so you want to separate from there. So, you know, someone using latest tag, okay, maybe that's a very low severity. And then, you know, someone with a really critical vulnerability that's fixable, hey, like, someone needs to jump on this, you know, this is a, this goes to a pager duty, for example. Pretty cool. That's awesome. Yeah, there's, honestly, I feel like Kubernetes also favors the meticulous, right, in that aspect. You have some applications in a namespace. Everything's going to revolve around those labels and annotations and how you separate your workloads. So, I always used to tell people getting that, that first the namespace setup for your application is that core base that you're going to build all your policies off of, right? Yeah, exactly. Some namespaces are just naturally more sensitive than others, right? Like, you have a namespace for the payments team, right? Yeah. This is going to be a much more stringent from a security perspective than, you know, a machine learning thing that's that, you know, a namespace that's never on the internet, right? It never exposes, has no load balancer. And so there's kind of a large variety of different constraints that you have. And namespaces that allow you to, you know, also within our platform say, oh yeah, these namespaces have these rules. Even this cluster in these namespaces have these rules and these other namespaces don't have these rules or, or, you know, here's what we care about and here's what we care about. So you can kind of separate that by team and namespace. Yeah. And if you do it, right? You don't have the teams pickering with each other over resources. I think that's why we got to sharding of clusters. It's just, hey, here's your cluster, here's your cluster. But then you get cluster sprawl. So bringing that all together is interesting. Speaking of which, audit logging is coming up next. Enabling audit logging, I think by default most clusters nowadays have, and most cloud services have some sort of audit logging functionality. The biggest issue is, what are you looking for? How do you monitor it? And what are the things to look for, right?  Are you looking for, you know, QCTL execs? What are the main things we need to look for? Right. Yeah, I think anything that's directly interacting with pods is kind of like, you know, especially those execs or port forwards, right? Like those are things that I would be concerned about. And then also typically if you're, you have an RBAC setup, right? You don't want a lot of people to run kubectl commands against your cluster. Like I think, you know, when you're really at the production level, you don't want systems like that or people necessarily directly interacting with your cluster unless you have to, right? And so that's the stuff you want to log and that's the stuff you want to look out for. And like, you know, we recognize this for sure because, you know, port forwards, yeah, you can have a direct local host to a server, right? Potentially bypassing different things or different like firewalls or load balancers. And then like lies with execs, right? You're in the pod.  And so actually if you want to flip back real quick, I actually really love this feature that we ended up building and we pipe it through actually the admission controller. So, so you can kind of default deny them as well. I'll go to the violations here. I'm on my terminal, but I'm just port forwarding to or sorry, exacting into one of the Stack Rocks pods on this cluster. Nice. Can you zoom in a little bit? Do you mind? Oh yeah, sure. On the dashboard. Perfect. Didn't really do too much kind of automatically shifted there, but right. So I'll exact into the sensor pod in like all live demos and slightly stressful. Oh cool. So yeah, right. So I just popped right up so we can see that. Okay. We had a Kubernetes action. We exact into a pod and actually if you break it down, you can see that it was me that I did this and like what group I'm a part of. So okay. An authenticated user did exactly to this pod. What you can do is kind of trace these breadcrumbs that if we go to the risk page and look at, for example, the deployment with the sensor in this case, there's two of them. But we can see that this one actually found an anomalous process and I got a process discovery here and it's SH, right? And so I just had opened a bin at SH there. Let's see how I can do here. I reload this real quick. If you picked up all my other stuff that I was doing. Yep. So I ran LS, right? So right, you can kind of like, there's some breadcrumbs to follow here in terms of what processes will run. And this red indicates that we found it's anomalous that we've basically been running this container for quite a while or this pod for quite a while. And we've only ever seen this Kubernetes sensor. It's a go binary. It's very easy to tell that this is the only thing that should be running. And then these are the other processes that came, after we've baselined it, we're like, hey, these are new, these are strange.  In this case, I'll leave them because they are anomalous because I exact them. So you can kind of immediately see that. And then we also have the ability for everything that you can highlight through alerts, you can also reject them through the admission controller. So if I change that policy, I could make it reject my exec. Now, when it rejects it, does it delete the pod? So from an admission controller perspective, you can like, you're just blocked. Like you just get a report back to KubeCuddle that your action got blocked. But if you have other runtime data around processes, for example, that's actually running, right? The pod may be already running and then you see some anomalous processes. There is an option on the enforcement to kill the pod. And we'll just kill that through Kubernetes. We'll say, hey, we saw something strange, let's just kill that pod and you can see if it happens again. Again, always be very careful with this, right?  Depending on whether they'd be a little bit more sensitive than others. And so those are some of the concerns just on that strident enforcement, but we'll always show you the violation as well. So you can pipe those to, you know, some more like incident response. Yeah, and having the context of who's doing it, obviously is a huge factor in that decision. But I mean, just blocking the action alone. And then if you're able to delete a pod, if you do have a highly available deployment, deleting a specific pod or enforcing that rule should be okay, right? It really, you obviously don't want to set that as the standard, but then you hope that people have set up their deployment correctly, but, you know, deleting a pod, there's no massive impact, right? It's a little bit different from like wiping a whole workload for a security issue, right? Yeah, yeah, exactly, exactly. Those are kind of like the main issues there. Yeah, and that's what I actually really like about the admission controller on creates, right? Just in general, is that you're usually not changing the state of the world, right? Like someone's trying to create a new deployment. You can be a little bit more stringent about, okay, what hits your cluster at that point because it's not currently running. And so it's kind of just staying in the same state that it is. When you run admission controller on updates, for example, that one's a little bit scarier, right? Because you could be running, you know, just critical updates or image update, but now you're violating some policy and then, you know, that could be rejected at that point. And so, you know, you're still staying in the same state, but it's a little bit more risky from that perspective in my opinion. Definitely. Yeah, we got a, Kevin, I'll post all 10 in the chat at the end where we're just getting on to nine. So two minutes and I'll just copy and paste the whole list that we made. You kind of mentioned it, touched on it a little bit, but that providing a secure software development process, now this might be the most vague out of all of them, I think, because everybody has a different software development process. Real quick top things in a container build to deployment in Kubernetes, what are your thoughts? Yeah, so, you know, let's start with the source code, right? Like you always have to have some sort of like source code scanning, linters, you know, just general hygiene around your code, right? The earlier you can find something, the better. Then you take that code and you put in an image, right? And then now you still have the same sort of hygiene around that image. Let's make sure you're scanning your base image. Things are up to date. The number of times I've seen something like, I'll find three point in someone's environment, right?  And then, you know, when you're crafting your deployment yamls, right? It's like, what is my service actually need? And how do I validate that, right? So, you know, does this thing need to run as privileged, right? Do I need these capabilities, right? Do I need like NetRaw, which is by, which is a Linux capability that's by default available, but almost no one needs to do transparent proxying, I think is what that allows you to do. So very few situations where it's actually necessary, you know, and then, you know, setting your users and UIDs and GIDs and all of that, like kind of fun stuff, like that's kind of the nuts and bolts of like, how do I actually run this service and making sure that you're not running everything as root is kind of like a really good place to start with that. Yeah, I'd almost recommend security teams if there's some sort of template, like you can take YAML files, right? Just take one that's been applied to a cluster, pull it out, set some defaults and give it to the development team and say, hey, fill it out, right? Let me know what's going on in your process. And if you don't know, you have a month or two to get back to me on it, right? It just for teams that are just starting. I think that there needs to be a little bit of communication there about what's expected. Thanks for bringing that up because I actually skipped number three. I started talking about secrets when we should have been talking about security contexts. I think that was probably the biggest thing, especially with pod security policies getting deprecated. You touched on it, Linux capabilities, UID, GIDs, dropping privileges, what else for security contexts should we get? Yeah, I think those are some of the main ones. I mean, if you can use some of the more advanced options there, you have like Secomp or SE Linux, if you can use those, then that's great. I know those can provide their own challenges as well. But those are kind of like just the places to start from the security context perspective. I think, yeah, I think the user one is just big. That just helps just move you out of root immediately. One of the ones that's maybe not in the security context itself, but I actually really like is the read-only root file system. So a lot of general attacks, if you look at Metasploit, for example, a lot of the attacks go to slash temp because that has been traditionally writeable on every file system. You dump everything in there. Forever, and there's a lot of applications that assume that slash temp is writeable. But for example, we're running a sensor, it's a go binary. It doesn't write anything, right? And so, okay, how can I utilize that fact to just reduce the service area of like anyone running an attack against our container, which is also the entire file system read only. And if you try to drop a payload, you just get rejected, right?  Sorry, your attack surface. And it can be complicated to run. I mean, sometimes you write lock files or things out, but if you can analyze that and just put even like a volume there at those locations through Kubernetes, Docker volumes don't work exactly. Yeah, FIGMAP or something like that. Correctly, yeah, but you can create a volume like just a temp volume in Kubernetes and put it at that spot and the rest of your file system can be read only. And so even that provides a lot of protection from that standpoint. Nice, yeah, and you mentioned SELinux. I found one of the better workflows security team tends to be, I'd say you security team handles SELinux. If you can hand off the deployment file with the list of permissions of user IDs and capabilities you need, you can let the security team figure out a lot of those aspects for SELinux on the host without even having to get into that aspect in your Kubernetes clusters. So yeah, it's just sizing up what responsibilities are where and having that communication I think is one of the biggest challenges. All right. So this kind of bleeds at four and 10, right? So four is like pot security policies and 10 is configured mission controllers, right? As pot security policies get deprecated, right? I think they are basically going to be replaced with admission controllers, right? And so. Yep, it's an admission controller, I believe. And there's, I think there's three in monitor, watch and force. There's like these permissive, medium permissive and very strict. Right. So the admission controllers that things that you can use as pod security policies go away, you know, our platform has an admission controller, you know, like things like Opa gatekeeper in the community, key verno, different things like that to be able to provide some of this context here around security and providing that in a generic way. So I think those are kind of one of the main ways that this will be, you know, you'll do pod security policies, I guess, is kind of replacing them with kind of like, also what's nice is that they're a little bit more generic as well, right? Pod security policies are pretty tightly confined to very specific aspects of your pod and admission controllers can check a large variety of things just around configuration. Yeah, sorry to anybody watching the copy paste interview stream is not great. So that's just a big word soup right there but I'll try to format a little bit. Yeah, one of the, I understand why PSP deprecating is a conversation. We're really still talking about security contexts. It's just, how do we wrap a policy around it so we can actually operationalize that, right? So it starts with just making sure that the security contexts are working for each application and that teams are caring about that and it makes the application of whether it be PSPs admission controller, OPA, OPA, KVRNO makes it so much easier, right? They're just layers of abstraction built on top to help you scale. Yeah, exactly. You're just, you know, it's just a nice method of enforcing that, hey, you guys are using the right things or that you're not running these things as root or at least you have the exception or like we can audit what's going into the cluster because I think one thing that's happening with Kubernetes in general is that there's a lot of like deployment responsibilities now on developers and developer teams. And so, you know, in a lot of ways, I view it as application teams or responsibilities to write and ship applications. And of course those should be secure, but that might not be their forte or their area of expertise. And so you kind of need these guide rails and guard rails to say, hey, you know, this is how you should deploy this or you probably shouldn't run this as root. Is there a good reason? And a lot of times it'll be like, oh no, we can run it as any other user, like just let me know how to do it and we'll just run it as, you know, some other UID. Yeah. Yeah, and that conversation works a lot better than, hey, we've had no policy, let's implement these policies across all our clusters really quickly without any information about their deployments. That'll be a lot of friction that you're creating with something like that. So, yeah, 100%. That's our top 10. I will try to post a better comment in a restream for anybody watching. Kevin, hopefully that helped you with the notes probably made more work for you, but there's the top 10. We did have a couple hot topics. What's next? KubeCon was last week for those who missed it. All the videos are gonna be available online, and I think in the coming weeks, they did a good job with the hybrid setup. Definitely extremely challenging. I liked it at home because I got to, instead of, you know, setting your schedule where you have to go to all the events, like you can just binge watch a bunch. But want to talk about, you know, hot things. Supply chain security was a huge conversation and specifically container image signing and verification, cosine, you know, building and signing images with Podman. Wanted to get your thoughts on maybe proper implementation is, I don't think it's a great tool. It's another tool in the security arsenal. I don't think it's the silver bullet that people think it is. What are your thoughts? Yeah, I think that's super true. I think it's a really cool tool and I think that it does definitely have like good security implications, right? That like, you know, kind of verifying things that are going into your registry and being able to attest where they came from. Now, this sort of happened with SolarWinds, right? Which is, I think, you know, big reason why a lot of these conversations have kind of come to the forefront, but, you know, if the supply chain itself is compromised, then like you could still sign bindings and things that have issues, right? So it doesn't fix all of the issues, but definitely addresses like, you know, malicious images in your registry that didn't come from where you think they came from. And so I think that's... Like injection through a knit containers or something like that, right? If your workload is not supposed to have anything added to it, something happened during the knit process, you'd be able to see that, right? Yeah, exactly. But those can also be caught with existing runtime setups, depending on what you're doing, right? Yeah, absolutely. I mean, I think, you know, the more mitigating controls that you have, the better. And so if you can, you know, a combination of those two things is probably best, right? I think a lot of times, you know, we like to look at, oh, security is like, it's just a multi-layer process, right?  And so sometimes, you know, it's not one product is your silver bullet, right?  It's kind of like, yeah, you have a bunch of these things layered together and you can utilize the best of each. So I'm a pretty big proponent of that. Yeah, one of the best, probably in terms of operationalizing it, one of the best things is you can do it with the security team can just implement it. Like most likely your developers have set up a container build process that you just basically need to add on to that to sign and verify it and you can build it into your CI process without a lot of, let's say friction between teams because that existing CI system is already there, right? Right, yeah, I agree with that too. It's like, yeah, it should be fairly easy to go implement these things. And the final part is like, okay, the actual verification process which is interesting as well, right? It's like, you have to get, now the last part is, of course, when you go deploy these things, let's go verify that this is what you think it is.  Yeah, exactly. We talked a little bit on to the next hot topic. We talked a little bit about ephemeral containers, Kubernetes K, it's 1.22, it moves into Alpha stage. Is this going to change some security workflows? So like ACS, which had Cuba CTL exact notifications? I think that still remains there. Do we need extra security around ephemeral containers too? I mean, I think it's another thing to watch, right? Like if someone's launching an ephemeral container, that's something that's kind of out of the norm, right? I expect this to not be launched all the time. From a security perspective, I actually think it's a plus because you can build images that are way slimmer now. A lot of times you'd build an image with maybe some network tooling in it, just in case you needed to like do DS lookups to ensure that like something is working, right? Or like, why can't this namespace talk to this namespace? I think network policy debugging network policies is a really hot topic there where, these two things can't talk to each other, you're trying to figure out why, you really want to run a curl between these two services and be like, what's going on? But you may not want curl in your main image, main application that you're running, because that could be used by an attacker, for example, to download a payload. So in a ephemeral container, right, is just you have all your debugging tools all set up there and the whole point of something that's ephemeral is that it doesn't run that long and that way you can kind of run your debugging and tear it down and move on. I think they're missing the tear down part right now. I think it will stay in the pod for the lifetime of the pod, last I looked, but, you know, for the development standpoint, it seems to be the most applicable. You can tell all the developers in your team, hey, here's an image with every single tool that all of these teams need. You guys can all use it to check your application, just run this one thing. But, you know, you take everything else out of your image that you would normally use and we're alerting on this in production, right? Sort of thing? Yeah, exactly. It gives them a way to respond to the question of like, oh, how do I debug my container in Prod, though? Right, and it's like, here's this formula of how you do it and please remove everything else from your image because we're literally giving you an image that can do this, right? And so it's kind of like a bargaining chip, I would say because I think debugging things in production is always difficult and so this at least gives you kind of a way that you can have application teams use this. Very true. All right, last topic. Validating true security threats and metrics and touching on this a little bit with vulnerabilities. Vulnerabilities never really go away. How do you triage it? Another aspect is how do you validate that the security choices that you're making are helpful to your overall posture? What does that look like and where are the security tools going in terms of measuring that? Measuring risk is always a tough conversation, right? Yeah, no, yeah, I think that's a really good question. I don't have all the answers, unfortunately. Yeah, I don't think anybody does. But yeah, I think a lot of the stuff around configuration and really trying to scope it down as much as possible is really useful. I mean, there's always some edge cases here and there where things need special privileges. I think when you think about measuring risk in a Kubernetes environment, you have a lot more data, right? And like you can start utilizing some of that data to really influence your decision. So you have things like, okay, you have a vulnerability and you have the vectors for it. If it has a network attack vector, for example, like is it exposed on a load balancer? Do you have network policies set up in that namespace to deny access to it? It's like, how do I quantify what really has a lot of risk? It's like, something that's a severe issue that's exposed over the internet. It's like, yeah, I wanna go look at this, right? And I wanna go try to address this issue as fast as possible. Another aspect, something that we just shipped, it's not in this demo, unfortunately, is around the concept of active vulnerabilities. And so how can you see what is actually running? Is this vulnerability potentially exploitable because there's a process that's using this library, for example. And so that helps you provide even more context around this vulnerability and it's like potential to be exploited. Is it in a process that's running? In that case, I'm like, hey, like, wow, we should go look at this immediately. And probably how many containers too, right? Like if it's a base image issue and that base image is being used across the cluster, that's a high impact, right? It's in how many different running containers. Right, exactly. And sometimes you wonder because there's different things in the base image that you never use. Are you, you may not know you're using or you honestly just never use, like sometimes they come with Python, for example. We write Go applications. We never call anything in Python. And so it's like, how risky is this Python bold if we never call Python ever, right? And so you can kind of drop the risk of some vulnerabilities and raise up the other ones based on how active they are. Very, very, very true. And that's to some extent that requires a little bit of user input too, right? And people being aware of the applications that they're running. Right, so this is kind of the value of having a whole runtime component of our product as well, right? Is like where you can look at what are you actually doing, right? If you think about network flows, for example, it's like, okay, how much network flow traffic have I actually stopped? How many violations around networking have I actually created that are of value, right? You know, looking at, you know, one thing that we could look at in the future or something is around file writes and whether or not you could create things read-only file system or influencing, influencing configuration based on what's actually running, right? Because I think the concept of knowing everything before you deploy an application is just a pretty challenging situation, especially if you're deploying something off the shelf. I mean, I run, engine X is always the container that I use. I, you know, I could cuddle run an engine X. I still can't tell you all the processes that run as a part of that or what files are written or what network activity is used, you know? And so, or like what port is opened by default? I think the fact that ranchers no release they drop the engine X default backend. I was like, yeah, it's the defaults. I think that as Kubernetes gets more mature, we're starting to realize what defaults are useful, but that's a little funny engine X. It's always the default test container. Yeah, it is. And for good reason, it seems to always work, right? Yeah. That was always the huge benefit when starting with Kubernetes. It's like, if I take this Helm chart and it works the first time, I'm gonna stick with it for a while until somebody tells me not to. But yeah, that's awesome. Anything else that you're looking forward to? Security space, changes in Kubernetes? Not too much. I mean, I think there's always a lot of interesting movement in the community. And I'm curious to see what the next sort of, they're not RFEs, but the kind of like improvements and the kips, I think they are, the enhancements or caps, sorry. Really curious to see what people have there and what people wanna move forward, especially as Kubernetes scales and needs to get more scalable and there's larger clusters that are being created. And so there's always gonna be interesting use cases and stuff that pop out of that. Nice. Yeah, if anybody is checking us out and wants to talk about a use case, wants to tell us to test something out, you can ping us stackrocks.io, go to the stackrocks.io community and there's some emails, bunch of docs and some communication stuff, shoot me an email and I'd be happy to chat about it on the future streams. Connor, thanks for coming on and walking us through the top 10. Hopefully we'll have you on again soon. Possibly. Yeah, sure. Anytime. Yeah, it's super fun. Nice. Anybody else watching have a good, I guess I could say weekend, right? It's Thursday. Just say good weekend.  Yeah, awesome. Thanks for joining. Thanks for listening to the top 10.  Bye.


My name is Fei Yao. I am chief architect for SAP. I have been working on cloud and cloud data for a long time. I'm really passionate about using cloud-native technology to build highly available, highly scalable, and secure applications for enterprise. Today, I'm with Nick. Nick, you want to introduce yourself? My name is Nick Niles. I'm a field engineer at SoloIO, and we've partnered with SAP to help them design and implement their ServiceMesh strategy organization-wide. I'm going to hand it back over to Fei to talk about what they're doing with ServiceMesh today and what they're going to be doing in the future. SAP as a technology company includes a wide range of verticals from IoT to machine learning, artificial intelligence from blockchain to big data, from cloud computing to intelligent cloud, and a couple of wide range of application and services, which includes EIP, finance and CRMs, spend management, people management, supply chain management, and many, many more. We offered over 50 plus data center globally, running our workloads across multiple hyperscalers, AWS, GCP, Azure, and Ali cloud, together in our hyperconverged data centers. We have heterogeneous environments. It's a hyper cloud environment. We use our Kubernetes service called GUNNER as open-sourced Kubernetes service to manage all our Kubernetes workloads. We have over 7,000 clusters across globally. All of those services and application rounds on top of Beniz technology platforms, short for BTP, really is a try to bring about intelligent applications with database and data management, analytics, integration, extension capabilities into one platform. That one platform for both cloud and hybrid environment, it truly makes us the best Beniz cloud in the world. Yeah, many live Beniz currently either has been using service mesh already or in the journey of adopting service mesh, such as Concur. Concur has been using service mesh way before its deal, Concur using envoy-based proxy to manage all the workloads. Ariba is our e-procurement source to pay in a supply chain cloud solution. Ariba will use service mesh to bridge the multi-cloud hyperscader clusters to build that service mesh fabric for the interconnectivities. CSE is our intelligent cloud suite. It has been using STO for its production workload. Kima is our open-source solutions extending application with service function and micro services, which is run on top of Garner. SuccessFactor is our faster growing human resource solutions in market. It is in the journey of adopting service mesh as well. The artificial intelligence framework is using service mesh as well. For example, so SuccessFactor is one of the forerunners to try the technologies to bring this technology to the bigger organizations. Currently, SuccessFactor is only a small part of it. One of their services, micro services running in the hyperscader and another part of it, machine learning service, runs in the virtual machines in our converged cloud environment. This is truly hybrid cloud solutions. Right now, there are a lot of complexity components we're using console. We build a service discovery into the applications, but we want to move more and more of this network, a related function such as service discoveries, low balancers out of the application and let engineering teams focus more on building features for our customers. More importantly, for the workloads that are not suitable to run the container as environment, in this case, be able to join service mesh and benefits from the service mesh or the benefits that service mesh provides like containers running in the Kubernetes. AF is another front-runner project which is run in 250 workloads. It has over 3,000 parts per cluster. It's running the KF serving and the service environment. It is using Istio to manage all their traffic internally. I think you showed off some of the lines of business here at SAP that are using service mesh, but they're using a wide variety of technologies to achieve that service mesh solution that they want. Can you talk about how a business technology platform is getting involved with these lines of business in terms of service mesh and adoption? You can tell various lines of business at a different stage of either using or adopting service mesh. As a company, we really want to step back, think about how should we standardize service mesh with various capabilities including routing and security, etc., and really remove the burden for each line of business and build a service mesh as a service. Great, thanks. You mentioned security. I'm sure as most of our audience has seen and read this article from the NSA about adopting a zero-trust security model. I'm assuming SAP has a top of mind when adopting, probably a reason why you're adopting service mesh is to solve some of those problems. Can you go into more detail about what SAP is thinking about in terms of security and what you think about the zero-trust security model? On the next slide, I know this document talks about pretty much the hardware all the way up to the software, but we know with service mesh how SAP is dealing with limiting access to applications and sensitive data. Yeah, absolutely. Security is paramount in our industry. The world has changed from trust by verify to never trust always verify. That assuming bridge has happened and bad actors has already in your network is essentially the mindset of their trust. Following DevSecOps and shift left security principles, service mesh allows us to build security from a get go without the heavy lifting from product engineering teams. Of course, security should always be later approached. There are other aspects such as application security, data security should be taken care of outside of service mesh. For SAP at a minimum, we want to use service mesh to enforce zero-trust policies. For example, service-to-service communication must enable mutual TRS, and user authentications must be enforced before getting to network, and all workloads must implement non-passable policy enforcement points to deploy fine-grained access control policies. It is still worth such as authorizing policies has to be in place in all workloads. Last but not least, access logs must be enabled for the later forensics logging and auditing, etc. And a couple of things to really stand out. Fundamentally important, one of the PKI's at SAP, we have our tiered PCA infrastructures, and we have our off-light root CA from SAP. Then we have intermediate CAs for various landscapes, one of the service mesh. Then we have a tier two CAs to drive the certificate change, essentially issue the certificates to the workloads. Do you want to talk a little bit about why having a really strong PKI infrastructure in place really enables you to utilize service mesh to a greater extent? Yeah, I think that most of the secure bridges are at exploitation of the old trust model, and without identity, there would be no trust. Identity has to be given and verified and authorized and also tracked. Hence, there is authentication, authorization, and auditing. And tools such as spires can help issuing universal identities and build a trust and scale. So we've talked about a lot of it, what SAP is doing and architecting in terms of service mesh, but how do you actually plan on delivering service mesh to these lines of business in a unified fashion? That in itself sounds like a pretty tall order. Yeah, absolutely. It involves many, many parts. Ideally, at a BDP, we want to offer a given holistic architecture or technology guidance across the whole landscape. And in particularly internally, we have a project called ATOM. The goal here is really is to build a mesh and a service to build that dedicated infrastructure layers that can take care of all the network functions for service-service communications within the clusters, among clusters, and across clusters, across AZs or geographic boundaries. And if we go one layer deep, this is of course, the core of the ATOM is really built around service mesh. And we also want to bring the API gateway into this as well to bring traffic north, south, east, west as a whole to get a provide token services and a private identity as certificates to build this as a service as a managed service provided for our online businesses. If you let's dive one layer deep on this typical building block we have as a single cluster, all workloads will have ingress and egress. All workloads will have full observabilities building to track to have metrics, logins and metrics. And policy can be either enforced through a steel authorization policy or through external authorization such as OPAs. And we will use our existing PCA infrastructure to issue certificates. So this is a building block for mesh and services. From this building block, we have multiple layers of meshes. From the very left, we can consider it as a single cluster mesh. Then move up to the right depends on the organization structures and the team structures and responsibilities. There is a need to have multi-cluster meshes. And then move to the layer two, to see that even bigger LBs have geographically distributed for multi-clustered environments such as Arriba. Arriba runs in the GCP also at the best as well. We need to provide the capability to use the service mesh to bring those together. And last but not least, we want to we want to view this, view the traffic from north to south, from east to west as a one network fabrics. In other words, traffic typically before for one LBs, we have to go egress, outbound, internet, come back to another line of business, not only has security challenges into the compliance, but also increased latencies. We want to use service mesh to be able to bypass that, allow new 2TS amount, line of business, without going outbound during the data come back. If you look a little bit deeper on that, what we try to achieve here is one line of business on the left, the traffic workloads, if they intend to reach another workloads into another line of business, doesn't matter its geographic location, it all goes through egress of its own mesh and go to SAP managed edge gateway. And those edge gateway will be provisioned through SPIR, which is speed implementation with federation to provides mutual 2TS, which provide a universal identity on those line of business and a traffic from one line of business to another line of business, also mutual 2TS. So we are very exciting for the service mesh journey, definitely still a work in progress. We are continue looking forward working with communities and industry leaders. With that being said, I want to also thank many technology and engineering leaders and architects for their visions and continue the efforts around a service mesh for SAP. And with that, I will conclude our talk and thanks for your audience. Let us know if you have any questions. Thank you very much.


And how I want it right by today's title. I was gonna be going on her first date today What's up YouTube?   Maybe you should make a change fat tea Hey guys, it's Madison. Welcome back to my blue kitchen for another crazy video Today we are diving into the dark side of family vloggers and this is going to be a really crazy video Yeah, first before we get into this video if you like deep dives and like to analyze scams and other crazy things going on on the internet Don't forget to subscribe down below and give this video a thumbs up to boost this video Well, let's get into it for years family vloggers have been the youtube poster child's literally for family friendly content on youtube But recently with the horrible situations coming out about Micah Stoffer and eight passengers I started to wonder as i'm sure many others did whether or not family vloggers are the perfect Advertiser friendly content that they claim to be there's no doubt that content deemed kid friendly Does the best on youtube with stars of the family vlogger realm Reaching massive success and making millions simply by pressing the recording button and putting their perfect family and awesome life Onto the internet only it's not that simple today We're discussing the ins and the outs of the family vlogging business because yes It's a business and the dark side of these youtube stars that may slowly ruin the platform that they reached all of their success on First off, I do want to make it clear that I am not a parent myself And I could never even begin to understand the real life struggles of parenting Kat can you stop? Yeah, too much. I know some really amazing and loving parents watch my videos So I'd love to know your guys's thoughts on this topic over the last few years family vlogging has become an extremely powerful And fruitful industry children's or family friendly content is known to get the best ads on youtube It's usually pushed out the most to a broader audience because it's deemed Suitable for everyone to view and if you're smart as a family vlogger You'll expand your platform off of youtube onto other social media platforms like instagram And build a brand for each member of your family so that they're able to promote and gain sponsorships individually and collectively as a family So it's like building multiple brands into one and you can see that with a lot of family vloggers out there Each member is able to sponsor and promote different products and services from a variety of different categories A lot of family vloggers, of course have their own merch as well as giveaways that could be deemed a little shady clothing lines Brand partnerships the money-making opportunities for family vloggers are literally endless There's only one component that every family vlogger needs to have a super successful channel And that's children Most family vloggers center all of their content around their children But also most family vloggers put out tons and tons of content So what does that mean in essence though? I won't pretend like i'm any sort of lawyer who understands labor laws These children are almost working every day to turn out content for their family channel And this is concerning for a number of reasons are the children given time to learn and play Are they being forced or coerced into making content using unhealthy tactics? Does this type of home environment create any type of stressful environment?  But the most concerning question for me personally is does the child have any claim to the money that's being made off of them? Social media is still fairly new in the entertainment industry And what comes with that are a complete lack of child labor laws and regulations that you would see in a place like hollywood Platforms like youtube and instagram are allowing parents and employers to sidestep regulations put in place to protect children in the entertainment industry For example, let's look at kugan laws And once again, i'm not a lawyer kugan laws mainly established in california Require parents to set aside a percentage of earnings from a child performer into a blocked trust account known as a kugan account This account can't be touched until the child comes of age So it's fully the child's money these laws were put in place because before kugan laws were a thing Parents would take all of the earnings that their child made as was the case for jackie kugan There are a lot of other child protection laws established for child performers and entertainers But the most notable are limits for how long a child can work so that they can have time for rest and recreation And making sure that no child is exposed to anything inappropriate while they're working The issue is at the moment no one on youtube or instagram is bound to these child protection laws And though some family vloggers may claim that they're saving a portion of their earnings for their child There's no laws to hold them to that and just like much of the content on youtube family vloggers often use clickbait Or overly dramaticized video premises to garnish views and this often involves their child having a Bad moment now. I know i'm not the only one who's had their fair share of tantrums as a child We all did and it's kind of a part of being a child learning growing and learning how to express your emotions But imagine your worst tantrums and your worst moments as a child being filmed and then put on the internet for millions to see I remember one time I had a literal breakdown because I couldn't remember how to tie my shoes And I would be mortified today if that video was filmed and put on the internet It's like a baby photo album but taken to the extreme You know when you have friends over your mom has to show them your baby photo album It's like that but put to an extreme and in front of millions I think that this is best summed up in the eight passengers family vlogging channel A lot of controversy came out about eight passengers when a lot of people became concerned about the potential mistreatment of the children on the channel a text message uh from ewes teacher and She said that Eve did not pack a lunch today. And can I bring a lunch over to the school? Bonded and just said Eve is responsible for making her lunches in the morning Hopefully nobody gives her food and nobody steps in and gives her a lunch I had just had Russell and julie was just Crying a lot and whiny and and one day I looked at her and i'm like you just stink. She had like Peter pants or something and she was just because she was being neglected because I was totally paid attention to the new baby My bedroom was taken away for seven months and then you give it back like a couple weeks ago But on top of that potential mistreatment the mom of the eight passengers family vlog channel Also openly talks about and shows all of the children's problems Whether it's acne problems in school or drama with the kids She puts it all out there for everyone to see Chad today has just entered the anasazi foundation wilderness therapy program Where he's going to spend the next eight to ten weeks living in the um Anasazi desert. Yeah the desert mountains of arizona worry if dad and I are gonna get divorced You do I did not know you worried about that How often do you worry about that? um Probably when you're at the most tired and then your mind starts Going to extreme cases No, what do you hear dad and I yell and fight a lot? You're supposed to say no Racers And you know what is driving me crazy Can I pop that other than the little zip there on your chin gives an update on your skin? You have been crying For like an hour. Okay, so here's the deal Here's what's happening Julie's birthday is coming up and I thought her birthday. They didn't have school her birthday's on a friday What did you ask that you wanted to start doing?   Do you want me to come up and sit with you in bed while you eat? You haven't eaten in In a while. I'm very lucky My mom always did a great job of taking care of me when I'm sick But I just can't imagine feeling at my worst feeling genuinely really sick And then having my mom bust out a camera to give me a popsicle and film me as I'm feeling and possibly looking terrible And then putting that out on the internet me at my worst Also, can we just know how the mom of eight passengers looks like a strict anti-vax essential oil loving facebook mom If she wasn't pimping her kids out on the internet, you know that she would be in all the facebook mom groups Thriving off of shaming other facebook moms for their parenting choices And possibly selling luluro and doTERRA You know, that's true This sort of allegedly exploitative behavior Allegedly can also make it seem like family vlogger parents are more concerned with the results of their vlog and the growth of their channel Than they are with their own children And if it appears that way to me as a complete outsider I can't help but wonder how it feels like to be a child in a family vlogger Family in a non-extreme case take the lebrant family for example last year the lebrant family Vlog channel filmed themselves pranking their daughter on april fools day by saying that they're gonna have to give away her dog Come here What's matter her give give him away It was all for a prank video on youtube But in the video you can clearly see How upset and distressed she was by that situation Of course, they apologized after backlash kind of alluded to this being an outsider case and that in general Everly was treated very well and they didn't take things too far for their vlogs But if you look at some of the topics of their other videos You have to wonder if that's the case or this has just been the only video that's been called out and has received backlash What if before Everly goes to bed we turn every purple so uh, did you know it? Didn't she realize Their daughter everly is the main subject of most of their videos And they often make videos that are sad or shocking that to me screen Very similar to the pet prank video and I can't imagine being in a home environment where that much Emotional turmoil is constantly happening. Everly also has her own channel a channel with her best friend The family youtube channel of course a personal instagram An instagram with her best friend and all of them have followings in the millions and the weirdest thing about the whole situation is the family mentioned having a savings account for everly But when the guardian asked for more info they declined to answer But of course, there are a lot more extreme examples of family vloggers blatantly ignoring or mistreating their children So let's dive into the micastoffer situation while I am definitely not an expert on special needs children the adoption process or the long-term effects of Re-homing a child I do want to know a few things regarding the micastoffer family vlogs If you didn't know micastoffer was a vlogger turned family vlogger That filmed an adoption process of her adopting a special needs child from china Her entire adoption process centered around this child Garnished her tons and tons of views and that's really how she blew up on youtube Except for when this child started to become a little too difficult to handle her and her husband made The difficult decision to re-home him or give him away because they found him to be a bit too difficult There are a lot of great videos on this already some from youtube friends of mine that all link below Of course, I want to put it out there. No one can ever know what happened behind the cameras No one will ever know But when the cameras were on micah made sure to exploit her child's entire adoption journey And her child's most vulnerable moments. Now. I don't even know if I want to call Her adopted child her child anymore. He's not her child anymore I hope that he's with a loving family who really works with him and loves him for exactly who he is But while he was micah stoppers child She made sure to exploit every aspect of his life Her channel really grew because of this adopted child and when you look at the home She lives in the sponsorships she has the jewelry she has You have to wonder how much of that money came from exploiting her adopted child That he will never see any of on top of that They openly filmed a lot of his tantrums as they called it We don't bite Biting is not Nice Like a tantrum No more. Come on. Let's go. You're not going to throw a fit when you don't get your way That's not okay. Let's go Are you done fitting It's him Multiple mouth downs not having a good day today. I never tell you guys the truth That's why you don't see it on the box Often separated him from the rest of the family and the whole thing really left me feeling like he was there simply to be a Show pony and to give their family diversity and an interesting story to increase their following But once it was actually time to be a parent they backed out the most heart-breaking video that I saw in all of this Was actually a video still up on their channel. Micah is teaching words I believe to their adopted child and there are so many points in that clip Where he tries to show her love and affection and she just completely turns him down I'll show the clip, but his face is going to be blurred. So it might be a little hard to tell what's going on Now, of course, I'm not here to mom shame anyone nor am I an expert by any means on parenting But I do remember what it was like to be a child Fairly, I was one believe it or not At least personally, I remember as a child being really sensitive to how people treated me I picked up really easily On when I was being given love and affection and when I was being neglected As a child you can sense a lack of love and affection and it really does hurt And to me it just furthers the narrative that he was nothing but a show pony to them And they never saw him as their actual child like they claimed even more extreme cases of very bad family vloggers are a daddy of five and fantastic adventures who literally Their children and were kicked off of youtube and faced legal repercussions for their actions But before that both channels amassed a huge following and were massively profiting from the harm and exploitation After these two incidents youtube stated that it works with the national center for missing and exploited children to arrest and convict Anyone whose accounts Depicked harm to children and supposedly youtube has deleted 46,000 accounts 46,000 you have to wonder how many more accounts are out there in this seemingly massive problem of children exploitation on youtube for example the Of the children on the fantastic adventures channel wasn't uncovered from the videos themselves The videos themselves were heavily edited and very scripted But they were very light-hearted and had that family friendly tone But behind the scenes the children were being forced into making this content using absolutely horrible tactics So even with the harmless videos on youtube youtube has no way of knowing how the children are being treated behind scenes And youtube itself may even be profiting from creators similar to fantastic adventures Who are mistreating children behind the scenes as we speak I just find it so bizarre personally and I know this is like a youtube creator thing that Creators that make more adult content kind of have a gripe with youtube about this But honestly if you think about it, why is it that youtube gives the most profitable ad revenue? to content creators who put children to work And very visibly exploit children and that's where all of the best ads go Really? That's what we're choosing here. It just personally doesn't make sense to me. Maybe that's just me But if I were an advertiser personally, I would not want my ads to be associated with child labor And even just potential mistreatment and exploitation of children If I were an advertiser, I'd much rather go with an adult than a child Who's kind of being exploited on the internet I don't know. I don't know why that's a thing on youtube. It confuses me If you have like a logical explanation, definitely let me know in the comments because to me I'm just like Make it make sense on top of that with millions of viewers tuning in to watch family vlogs It's impossible to know who exactly is watching Well, it's not impossible You can actually look in your demographics and I'd be really curious to know What demographics family vloggers who film their children in their most vulnerable moments What their demographics are Who is watching these videos exactly? I remember there was even a story of an influencer who had put their child on the internet And then actually watched their demographics change to a very disturbing demographic of older males And decided Nope, nope and took her child completely off the internet I've read it to take her kids off the internet after looking at her analytics And realizing that a lot of her videos were being embedded On basically the websites of They were collecting these videos and sharing them her videos were ending up on Predatory playlists and something I think is really bizarre that a lot of family vloggers do is they put their children In scenarios that are either met for someone much older than them or much younger Oh Well, you like to shy now, huh? Where is he taking you? Where is he taking you? Dad needs to know No, no, there's also a disturbing amount of family vlogger content Where family vloggers are giving their children very specific and very odd types of food These are so good. I always have loved these And you have to wonder what is your intention with all of these videos with Your children and putting them in scenarios meant for people much older than their age Or making them out to be like really young babies Or giving them really odd foods like what's your intention here? Who are you trying to expose your own children to? And it's really sad because even the very popular deemed Unproblematic or harmless family vloggers do this And they're put up on a platform and seen as like the perfect White bread cookie cutter family vloggers and then you look at this content and you're like is this really What youtube should stand for is this really like the poster child of the perfect content to make? But either way no matter what you are exposing your children to potential When you put them out there on the internet So before making this video, I was on the fence regarding my stance on family vloggers but But now I can confidently say I just don't think family vloggers should be a thing And if they continue, I think really really quickly youtube needs to establish kugan laws and other safety methods measures to protect the children that are working to create content on their platform Before more and more cases start to pop up You look at hollywood where the same situations happened and they put in place measures And you have to wonder why youtube just didn't see that as a foreshadow for what could happen on their platform And just implemented them immediately But for some reason they just haven't established major safety measures or precautions to make sure that the children On their platform are being protected Overall exploiting children is awful and terrible And there should be a huge hyper awareness of that stuff taking place in family vlogs And that's all I have to say on family vlogs and family vloggers Basically just no


Three reasons why patients pays in the dating process.  What they should do in fact is they should take it a little bit slower than they normally would and usually they'll be on pace with what the woman's looking for. So why does patients pay with women? Number one, she's trying to build trust and feel more comfortable with you, okay? Right off the bat, she may not trust you.  So she's gonna wanna protect those things. Thing two, it shows a lot of confidence. Typically guys that are not confident, they wanna rush in and get to the next step super quickly because they're worried the girl might not text them back or things might not work out. But the guy who's confident is comfortable with waiting because he knows he's gonna get there. Thing three, it gives you time to qualify her and see if she is the right person for you. This is actually something that a lot of high value guys do is they're not just trying to win the other person over. The other person is trying to win them over. Now, I'm gonna give you a bonus one that I normally don't give. It gives you a higher chance of success because women, their emotions go to kind of go up and down like they might be really into you one day and they might not be into you the next day. And if you're a guy who's trying to rush through the dating process and you find her when she's at a valley where she's like not feeling so hot for you, then you're gonna push her away and in reality, persistence and consistency is a very attractive quality, a very masculine quality that women are looking for. Cool, follow me for more tips.


What's up everybody Jason here for jaskiescasebrakes.com five spots and hip raid Cooperstown being given away here with this 2022 capstone MLB one-pack break number 73 And again, we'll do the break first then at the end we'll re-randomize the names top five get in guys The last pack fillers on the website down to 18 left that unlocks the Cooperstown dual casers So we're almost there guys almost there Let's do the break first though six into two. I mean sorry four into two six times one two three four five six Wow, so definitely turn colder, but no snow. Wow Decon's down to Decon's one two three Five six giant son of the Yankees Isn't that so cool that that chicks mutant superpowers? She's lucky So her me and the superpowers let me so anything she does it's a lot.  She just keeps like I'll be able to join I'll be able to join like no you can and like all right you're in We don't move on the dawn auto Lopez Beltran and Liam Hendricks to 50 The Chicago White Sox David with that one All righty Switch scenes and let's do that Cooperstown pack for there now Oh, I'll show them get the list. All right. We go guys roll One of three or one of two three times. Good luck one two three three times three times Top five James Decon's D Mac David with us all these these coming out of these and Stephen will get it. I had a box. It was just we hit all the we held letter D's All right, so Stephen David Darren Danny and James Congrats guys top five are in Thank you guys so much now again the last Capstones pack filler is on the website guys and again that unlocks the break So let's get that rolling Jasper's case breaks calm


This world is not just run by laws of physics. This world operates at one level according to the laws of physics and physics including I mean you know chemistry, biology and all that. But there is another level that supernatural factors also contribute. So for example if you want to understand how many years someone is going to live, you cannot just examine his body and diet and exercises and environment, there are other factors. How good he is with his parents, how he is connecting to this kinship, Selayih r-Rahim. All these things have role in determining how many years you are going to live, okay? So when it comes to success, one of the key factors is your good intention. If you have good intention, this world appreciates, people's hearts will be open to you. But if you have bad intention, things become blocked. Maybe temporarily with the force of money or with some tricks, you can open partly a space for you to function. But this is not going to continue for a long time. So good intention is very important. Prophet Shuaib said, my intention is only Islah. I just want to bring some reform, some improvement to your life. In oridu illal Islah, masta taqt, as much as I can. It means that I am not reserving any talent, any skill, any resources, any time, any energy. Whatever I have, I put it into this work, in oridu illal Islah masta taqt, as much as I can. Allah swt says, wa a'idu lahum masta taqtum min quwwat. As much as you can, you must prepare a strength. Prophet Shuaib also says, I don't want to accept Islah as much as I can. So no laziness, no miserliness, no relaxation as long as the mission is not accomplished. I tell myself, and you don't need this but I tell myself, we have many, many, many years to have rest in Barzakh. Now it's not time for rest. Now we must, as much as of course we don't harm our health, but as much as we don't harm our health, we have to work. There would be, God knows how many centuries or how many thousands of years we are going to be in Barzakh. So there is enough time for rest. Now there is no time for rest. Imam Sadiq said about mu'min, badannuhu minhu fi ta'a'bar, wa nasu minhu fi raha. His body or her body is made tired by him or her because he uses or she uses body a lot. But people are at rest. This is opposite to what we see many times, that people try to relax as much as possible and put pressure on others, but mu'min is opposite. Never burdens other with his own task and even tries to take part of the task of others so that they can relax. If I try to make you comfortable, this is good. If I try to make you able to rest, this is good. But if I do the same to myself, it is not good. I should not be planning for my comfort and convenience, I should plan for your comfort and convenience. So, mas tataat as much as we can, wama tawfiqi illa billah. And I know and I am conscious that my tawfiq is only coming from Allah Subhanahu wa ta'ala. I tell you something that I hope you remember. Sometimes we think it's not needed, we keep repeating that we need Allah Subhanahu wa ta'ala, our tawfiq is from him, everything is in his hand, inshaAllah we will do this. Sometimes we think it is in our heart, it is in our mind also because we have studied and acquired that we are dependent on Allah Subhanahu wa ta'ala. So we don't need to keep mentioning these things. But as a matter of fact, mentioning repeatedly your dependence on Allah Subhanahu wa ta'ala would facilitate your affairs. If you say, I do this inshaAllah, inshaAllah we will do it, we will do it but our tawfiq is from Allah in Allah's hand, we put our trust in Allah and we do it. You may think these are not needed because we all know as mu'min but no these are very important. Mentioning these things with intention means you are using these spiritual tools and this will change the situation. In Ramazan we had this series that spiritual tools and empowering aids or spiritual aids and empowering tools. So we talked about it. So it is very important. Like you know, Bismillah, if you say Bismillah and you do something it makes big difference. Wa ma tawfiqi illa billah, alaihi tabakkatu wa ilaihi oni. I put my trust in Allah Subhanahu wa ta'ala and in Him I put my trust and to Him I return. Okay? So Prophet Shuaib is very clearly saying that I am dependent on Allah Subhanahu wa ta'ala. I am doing everything out of my sense of responsibility towards Allah Subhanahu wa ta'ala but I do things wholeheartedly with maximum energy and power and talents and skills that I have. Imam Raza alaihi s-salam said, Man sa'al Allah at tawfiq wa lam yajtahid fa qad istahza abinafsih. The one who ask Allah for tawfiq, he ask or she ask Allah for tawfiq but does not make his or her best, doesn't make efforts, has ridiculed himself or herself. If you want tawfiq you have to work masta ta'at as much as you can and about good intention that we said. Amirul Mu'mineen alaihi s-salam says, Man hasunat niyyatuhu amaddahu tawfiq, the one whose niyyah is good, tawfiq will help him. So it means tawfiq comes when you have good intention. Dua is important. Amirul Mu'mineen said, alaihi kabbali ista'anati bi ilahik warraghbati ilaihi fi tawfiq. You must ask your Lord to help you and you must have yearning for your Lord fi tawfiq for your tawfiq. So if you want tawfiq ask your Lord for help and have eagerness towards your Lord. Another thing which is very important is halal resq. Halal resq is very important for a student, for a talab, for alim, for a teacher, for a speaker. Halal resq is very important because eating haram or things which are problematic will quickly affect your soul. Your soul would not be able to receive Allah's grace in the form of knowledge, in the form of understanding, in the form of wisdom. Having good temper is very good. If you are a person who has a very soft and gentle character and you are kind to people and you make people enjoy your company, this is very good for your tawfiq. Having good friends, if you want to succeed in your studies, choose good students who would be your friends. Those who have good akhba, those who study hard, those who are organized and punctual, those who are polite, those who are grateful, this would help you in many ways and it would add to your tawfiq. And one of the things that our Ulama have always highlighted is respect and kindness to your parents, whether it be your physical parents or your spiritual parents.