argocd-example-apps
intents-operator
argocd-example-apps | intents-operator | |
---|---|---|
18 | 10 | |
1,378 | 278 | |
2.4% | 1.4% | |
2.0 | 9.3 | |
3 days ago | about 9 hours ago | |
Jsonnet | Go | |
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
argocd-example-apps
- ArgoCD // Helm Chart // Dev/Staging // Your Best-Practise
-
What is better Github or Devops? We of the kubernetes Dutch podcast interviewed April Edwards. Normally the podcast is in dutch but this episode is in englisch.
I have not yet had the opportunity to test flux extensively. Regarding Argo examples, the Argo team themself maintain such a repo: https://github.com/argoproj/argocd-example-apps
- Did I miss something here, regarding network policies and helm templates? (Slightly ranty)
-
Am I missing something? (argo cd and helm in AWS)
Second, when dealing with OCI helm charts, look up the umbrella chart model https://github.com/argoproj/argocd-example-apps/blob/master/helm-dependency/README.md. This basically lets you create a helm chat that doesn’t do anything but call your next helm chart as a dependency. I use this with OCI stores helm charts all over the place. Also, in the next ArgoCD release, you should be able to get multiple sources for a sync, but we’ll see when that comes out
-
Argo CD and Helm: Deploy Applications the GitOps Way!
argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
-
Getting Started With GitOps For Developers!
Let’s Fork a sample repo, for example, like this one found here: https://github.com/argoproj/argocd-example-apps
-
deploy to different namespace from argocd
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: default source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook
-
ArgoCD installation
For example if I point to https://github.com/argoproj/argocd-example-apps, from the UI, I can see a new repository but no applications
-
GitOps installation
extraObjects: - apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-app namespace: argocd spec: project: default source: repoURL: 'https://github.com/argoproj/argocd-example-apps' path: guestbook targetRevision: HEAD destination: server: 'https://kubernetes.default.svc' namespace: test syncPolicy: automated: {} syncOptions: - CreateNamespace=true EOF
-
Fixing potential security issues in your Infrastructure as Code at the source with Sysdig
❯ cd ~/git ❯ gh repo fork https://github.com/argoproj/argocd-example-apps.git --clone ✓ Created fork e-minguez/argocd-example-apps Cloning into 'argocd-example-apps'... ... From github.com:argoproj/argocd-example-apps * [new branch] master -> upstream/master ✓ Cloned fork
intents-operator
-
Otterize launches open-source, declarative IAM permissions for workloads on AWS EKS clusters
No more! The open-source intents-operator and credentials-operator enable you to achieve the same, except without all that work: do it all from Kubernetes, declaratively, and just-in-time, through the magic of IBAC (intent-based access control).
-
Alternative to Network Policys
As you've mentioned, it is not possible to define deny rules using the native NetworkPolicy resource. Instead, you could use your CNI’s implementation for network policies. If you use Calico as your CNI you can use Calico's network policies to create deny rules. You can also take a look at Otterize OSS, an open-source solution my team and I are working on recently. It simplifies network policies by defining them from the client’s perspective in a ClientIntents resource. You can use the network mapper to auto-generate those ClientIntents from the traffic in your cluster, and then deploy them and let the intents-operator manage the network policies for you.
-
Did I miss something here, regarding network policies and helm templates? (Slightly ranty)
However, if you want to control pod-to-pod communication, you might be better suited with managing network policies using ClientIntents, which let you specify which pods should communicate with which, from the client's point of view, and without requiring labels beforehand. It's open source, have a look at the intents operator here: https://github.com/otterize/intents-operator
-
Can I create a NetworkPolicy with podSelector that matches a pod name instead of its labels?
You can try it out by installing an open source, standalone Kubernetes operator that implements them using network policies - https://github.com/otterize/intents-operator
-
Monthly 'Shameless Self Promotion' thread - 2022/12
Hi! I'm Tomer, the CEO of Otterize - a cloud-native open-source tool that makes secure access transparent for developers with a declarative approach to service-to-service authorization. Otterize allows you to automate the creation of network policies and Kafka ACLs in a Kubernetes cluster using a human-readable format. Just declare which services your code intends to call using a Kubernetes custom resource, and access will be granted automatically while blocking anything else. Give it a try! It's free and takes 5 min to get started. https://github.com/otterize/intents-operator
-
Creating network policies for pods with services
You can use https://github.com/otterize/intents-operator to easily configure network policies using only pod names by specifying logical connections (a->b, c->b), and the operator configures network policies and labels for cluster resources automatically.
- otterize/intents-operator: Manage network policies and Kafka ACLs in a Kubernetes cluster with ease.
- Show HN: Intents Operator, turns dev intent into K8s netpolicies and Kafka ACLs
-
What's your take on Zero Trust for Kubernetes?
I'm very passionate about this as I think cybersecurity and ops people lean too far into control -- controlling people, that is, not just programs, and they end up shooting themselves in the foot. Instead, I think you should make it easy for devs in your team to create the right access controls, and that this is the only way to achieve zero trust. Zero-trust inherently relies on all access being intentional and authorized, so if other engineers don't declare which access their code needs, it's impossible to achieve. There's an open source Kubernetes operator that aims to get this concept right with network policies and Kafka ACLs - make it easy for one person to declare which access is intentional and start rolling out zero trust using network policies, and have the access control policy live alongside the client code. Check it out at https://github.com/otterize/intents-operator. Full disclosure - I'm one of the contributors, so I'm a bit biased ;) I'm there on the Slack, so feel free to hit me up (Ori).
-
Manage network policies and Kafka ACLs in a Kubernetes cluster with ease
Hi all, I’m Tomer @Otterize. We just launched an open-source tool to easily automate the creation of network policies and Kafka ACLs in a Kubernetes cluster using a human-readable format, via a custom resource. Check it out - https://github.com/otterize/intents-operator
What are some alternatives?
microservices-demo - Sample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.
kubelet-csr-approver - Kubernetes controller to enable automatic kubelet CSR validation after a series of (configurable) security checks
gitflow - Git extensions to provide high-level repository operations for Vincent Driessen's branching model.
certify - :lock: Create private CA and Issue Certificates without hassle
argocd-autopilot - Argo-CD Autopilot
network-mapper - Map Kubernetes traffic: in-cluster, to the Internet, and to AWS IAM and export as text, intents, or an image
gitops-environment-promotion - Example for promoting a release between different GitOps environments
ziti - The parent project for OpenZiti. Here you will find the executables for a fully zero trust, application embedded, programmable network @OpenZiti
argo-cd - Declarative Continuous Deployment for Kubernetes
Lux - Lux is a command-line interface for controlling and monitoring Govee lighting, built in Go.
argocd-vault-plugin - An Argo CD plugin to retrieve secrets from Secret Management tools and inject them into Kubernetes secrets
pcreds - save ~20 seconds when copy/pasting to your aws credentials file from Control Tower