How To Secure Everything Without Making Everyone Suffer

[@DevOpsToolkit]

How do you secure your systems?

[@dzisonline]

You understand the power and point of Kubernetes so well. I need to master this skill.

[@Naren061982]

This is an university of information , awesome

[@devopscraftsmanship9302]

Awesome as always!

[@Capt_M]

Like always, amazing content!

[@felipeozoski]

Love this channel ❤❤❤

[@zenobikraweznick]

Tolkien be like: ""One k8s to rule them all, One k8s to find them, One k8s to bring them all and in the darkness bind them.""

[@jirityr]

How do you solve for the chicken & egg problem? How can you use such a great system base on all the tools around Kubernetes if you don't have any Kubernetes cluster yet?

[@DevOpsToolkit]

There are a few solutions. You can use a local cluster to bootstrap a "real" cluster. In that scenario, all you have to do is apply the same manifest you used in the local cluster to create the "real" cluster. From there on, crossplane in the real cluster would manage itself. The alternative will be announced this wednesday and I cannot talk about it until then.

[@jirityr]

@@DevOpsToolkit So what is it you couldn't talk about last week? ;o)

[@DevOpsToolkit]

Upbound cloud

[@hugolopes5604]

Just regarding policies and context... with opa we have policies that check other objects too... because opa can call the k8 api to get the extra context...

[@hugolopes5604]

This does not invalidate the crd aproach ofc... but sometimes one does really need to get data from other k8 objects or crds

[@DevOpsToolkit]

Not if that extra context was not yet created. When, for example, you execute helm install, there is no guarantee in which order resources will be submitted to Kube API.

[@hugolopes5604]

@@DevOpsToolkit ... in detail we are using a styra opa agent that has helper functions for this and the context includes all other changes being applied... our main use case is compliance rules whose context is some application metadata crd that is not generated by any other helm or controller... but you right, there might be cases where the context was not generated yet and we have to be careful with these context dependant rules

[@DevOpsToolkit]

@@hugolopes5604 Let's say that you have a rule that an app deployed in a k8s cluster should have multiple replicas. That probably means that you have rules evaluated when a deployment is created or updated. But, since scaling can be done in HPA, you need to take it into the account. Now, there might not be an HPA in a cluster (it's coming after the Deployment). Or there might be an HPA in the cluster but it would be overwritten by a changed HPA that will be applied after the changes to the Deployment. Or there might not be an HPA in the cluster and it's not going to come. Or... There are quite a few permutations to that simple scenario, and "real world" scenarios are even more complex. All that is not directly related to whether you use OPA, of Kyverno, or Datree, or something else to manage policies. It's a nuance of how Kubernetes works and it's not easy to solve.

[@hugolopes5604]

@@DevOpsToolkit , yes absolutly, I understood the hpa /replicas example and i agree it that example it would not work. but somehow our examples are more simple... like block containers with root privileges if the application data classification is high... because we modeled the aplication metadata as a crd , the context is another k8 object. Doing policy rules dependant of other k8 objects that some controller dynamically changes seems a bad idea, but is this representative of context dependant policy rules?

[@anshuman2121]

Awesome T-shirt. I also want one :)

[@erangrin1383]

Hi using sealed secret operator still using k8s secret mechanism so it's still only base 64. I think better solution will be using sdk or api to secret manger directly and inject secrets to application in real-time.

[@DevOpsToolkit]

I agree, as long as that does not require any "special" logic to be added to the code of the app. Apps should be focused only on business requirements. Also, you will still need kubernetes secrets for third-party apps since almost all assume them.

[@s1treyrr]

Would love to see a video on TUF (The Update Framework).

[@DevOpsToolkit]

Unfortunately, i haven't used it (yet) so I cannot comment on it 😔

[@jensherrmann7116]

Really Great Explanation of the concept. If all this concepts are in place the security guys will be extremely happy. But the guy who has to implement this will be completely overloaded. All the implementing Stuff is much to complex. 10 Tools just to roll out one App? In my Opinion the title should be "without making everyone suffer... EXCEPT the Devops Guy/Team" who has to implement it. The truth is no Developer wants to fiddle around with all this config tools clouds and everything else. You build it you run it? At the end you have a Infrastructure Team called Devops. What s the difference to the old days. I can tell you: the complexity. Your Explanation assumes everything works, but what if it does not work as a charme, which Developer will be able to trubleshoot when he or she only should work with Deployments in a Deployment Tool. Will a Developer suddenly know how all the Deployment Tooling works or how any cloud works (resources in Azure, AWS... and so on)?

[@DevOpsToolkit]

Developers cannot know everything. No one can. That's why companies are building internal developer platforms and trying to create the right levels of abstractions. Self service is the key and that does not exclude any roll but allows experts to offer their experience as a service.

[@Blablablateelbal]

Are you safe? Just kidding, I don't care about that. Thanks man!...

[@din956]

First 😂