Krumware

Final update for day 2 of #SUSECON25, I just got a new job….. video reporter for SUSE Cloud native ?? While Colin Griffin doesn’t decide where SUSE ranks in enterprise container management, it’s great to hear such enthusiasm from one of our experienced partners about our newly released DevX Validated Designs: "We think this is going to propel Rancher into the top position on the Gartner charts and beyond." In this interview, I speak with Troy Topnik, our product manager leading this initiative, and Colin, our partner who can’t wait to bring this to customers. DevX Validated Designs by SUSE are composable workflows that help enterprises streamline software development, deployment, and operations on SUSE Rancher Prime and cloud-native environments. Watch the full conversation in the video below!

?? At #KubeCon NA 2024, we spoke with Colin Griffin, Founder of Krumware and a representative of the Cloud Native Computing Foundation (CNCF) Platform Engineering Working Group, about platform maturity, challenges in adoption and how organizations can refine their strategies. ?? Tune in to the video to learn how you can get involved and contribute to shaping the future of platform engineering.

?Muchísimas gracias to Hugo Casas and others for contributing the Spanish translation for the CNCF Platform Engineering Maturity Model! Live and ready for your adoption here ?? https://lnkd.in/ee4FvVgC CNCF TAG App Delivery #platformengineering #cncf #morethancode

Did you know you can include secrets in your GitOps process? GitOps makes a lot of sense.... until you realize how hard it is to securely automate the deployments of credentials. But fear not - there are some actually extremely popular and sucessful tools in this space that will allow you to automatically securely integrate secret management into clusters. If you're unaware - 'Secrets' are Kubernetes resources that represent sensative information that applications and users in the cluster may need access too. Such as Auth Tokens, Passwords, secret keys and other sensative information. Kubernetes - by default - base64 encodes the key to 'obfuscate' it. but this is exactly ZERO actual security. Base64 just changes the base from base10 ascii table to base64. so to decode you just convert it back to base10 and map it to the ascii table. In Linux this can be done with a single command that looks like this: # -d is decode echo $B64_SECRET | base64 -d "So if they are not safe to store in git. How can I use gitops for every single application ever since it seems that especially with zero trust - my secret footprint is larger than ever?!" There are two main options here that are quickly becoming the industry standard. Both of these options leverage the concept of "one password to rule them all" (think lastpass/onepass and so forth). The most common I personally see is the External Secrets Operator (https://lnkd.in/gKR5Ejxm). This is vendor neutral and cloud native tooling. So, even if your organization is all in on a single provider now... they may not be in the future. This assures you wont need to change your core pattern for secrets management if you ever need to change providers or use an on prem solution. How this works is instead of storing Secrets in git. You store references (called ExternalSecrets) to the value in the secret store Such as KMS, Azure keyvault, Vault or even GitLab secrets. When this "reference" is deployed into the cluster the operator looks at the defined key that needs to be created and pulls it from the secret store. The other common method is SealedSecrets (https://lnkd.in/g2D8ig-a). Sealed secrets don't rely on CRDs as much but rather it encrypts the secrets values using a proper one-way-function such as sha256 so that the encrypted secrets can then be stored in git. The Secret objects are annotated which is watched for by a controller in the cluster. The controller will have its own secret key to decrypt the creds when they enter the cluster. Both of these method rely on the concept of a seed secret. That likely you will need to manage manually still (vault access for external secrets and secret key for SealedSecrets). BUT this is a dramatic cut down from manually managing all of your own secrets for every single application in every single cluster. Remember - the more we can take the human out of the loop in secret management. The less chance there is for a mistake. Stay safe!

We’re thrilled to welcome Krumware to the Open Commons Consortium team!? Through this exciting partnership, we look forward to achieving great things together and pushing the boundaries of innovation. Welcome aboard, Krumware team: Stephen Bryant, Colin Griffin, Hunter Adams, Richie Carter, —let’s make an impact! #datasharingmakesyoufriends

I've just learned that have the great opportunity to represent Amazon Web Services (AWS) with two Sessions at SUSECON 25 in Florida (https://lnkd.in/eDJAVC2X) together with my co-speakers Kevin Ayres and Nicolas Lowman. [TUTORIAL-1085] SUSE Rancher Prime as GitOps and application platform with Fleet and Epinio on AWS [TUTORIAL-1061] Paint it Green, automate migrations to SLES with SUSE Multi-Linux Manager on AWS My peer David Rocha and our counterpart at SUSE, Stephen Mogg, will be there too and deliver the Workshop: [HANDS_ON_LAB-1329] Using AWS to Automate SAP deployments (https://lnkd.in/eKmdsMMW). Want to learn even more about Epinio? Then checkout the session [TUTORIAL-1301] It's alive! Fast apps and self-service with Epinio (https://lnkd.in/ees2n62u) from my friend Colin Griffin at Krumware. Don't miss it, see you in Orlando from March 10-14! Learn more: https://lnkd.in/ed_R9Qnf David Duncan Samir Kadoo, MS, MBA Nick Panagiotidis Kabilan Mahendran Erik Orrgarde Ted Jones Sherry Yu Jason Vaughn #aws #suse #susecon #susecon25 #rancher #rancherprime #gitops #fleet #epinio #sles #susemanager #suma #sap

When it comes to kubernetes clusters - streching them across a L3 network generally leads to issues with reliablilty and scalability. Especially when the strech is across a public network where latecy is unreliable. Kubernetes can act in unpredictible and unreliable ways when latency spikes or routes change. For this reason - I would advocate against streching clusters. But what of East <-> West traffic for multi-region HA that just seems 'baked in' to cloud providers? Personally, I find the easiest way to accomplish this streched workload design be using a multi-cluster mesh via Network mesh applications such as Cilium or Istio. Service Meshes can span to the cluster level and these service mesh applications can facilitate this multi-cluster/multi-region paradigm very well. Secure tunnels that are not as latency sensative and more fault tolerant are put between clusters using east to west gateways. These gateways allow for services that can select pods across multiple clusters for seemless Multi-Region HA. Just make sure to use GitOps Patterns to keep clusters in sync! Heres a blog from Cilium on the topic (old but still relivent): https://lnkd.in/gs_y_mJV As well as a guide from the istio project: https://lnkd.in/gkXcRScz Combine this with a GLB to loadbalance the requests to each cluster and you have a recipe for a reslient, multi-region, highly-available and fault-tolerant infrastructure :)