rbac-tool
helmfile
rbac-tool | helmfile | |
---|---|---|
9 | 39 | |
873 | 4,024 | |
2.6% | - | |
5.0 | 0.0 | |
15 days ago | about 1 year ago | |
Go | Go | |
Apache License 2.0 | MIT License |
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.
rbac-tool
-
Getting started with kubectl plugins
Link to GitHub Repository
-
Data and System Visualization Tools That Will Boost Your Productivity
A simpler alternative to Krane is rbac-tool, which can be installed as kubectl plugin. It can also analyze, audit, interrogate RBAC rules, but most importantly, it can visualize them:
-
Interesting tools?
Tool to create and visualize RBAC in cluster: https://github.com/alcideio/rbac-tool
-
Kubernetes Multi-Cluster Part 3: Authentication and Access Control
Other tools that can also audit your existing RBAC permissions and Kubernetes setups are rbac-tool and rbac-audit.
-
What would make your life easier when using Kubernetes?
And of course a quick google search shows that someone has already created something like that for RBAC: https://github.com/alcideio/rbac-tool
- rbac-tool
-
Kubernetes Security Checklist 2021
Role-Based Access Control (RBAC) should be configured for the Kubernetes cluster. Rights need to be assigned within the project namespace based on least privilege and separation of duties (RBAC-tool)
-
Compiled list of ClusterRoles for better/safer RBAC
I've been tasked with defining and documenting some ClusterRoles with clear permissions that should (mostly) be enough for any kind of cluster. The idea is for admins (who don't necessarily do the devops behind) to be able to understand what each CR does, to assign these CRs to users on the fly, to update a user's access as their needs change, to view a list of policy rules, who can do what etc... For this maintenance and tracking part we use rbac-manager and rbac-tool, which are excellent tools imo.
-
Ask r/kubernetes: What are you working on this week?
I've just started using rbac-manager and rbac-tool to apply and track rbac on our clusters :)
helmfile
-
Deploy IRIS Application to Azure Using CircleCI
What we’re going to install into the newly created AKS cluster is located in the helm directory. The descriptive Helmfile approach enables us to define applications and their settings in the helmfile.yaml file.
-
[2022] [Updated] Alternative to Helmfile
Is there any alternative to https://github.com/roboll/helmfile you are currently using in your company.
-
Projectsveltos: Manage Kubernetes addons in multiple clusters
Interesting, I have approached this problem using Helmfile (https://github.com/roboll/helmfile) to define a “platform release package.”
-
How are you handling ILM on kubernetes?
To make managing the Helm deployments a little easier I used helmfile (https://github.com/roboll/helmfile).
-
Helm Charts Microservices
But in general it's always easier to keep things quite separated. Meaning in separate helm releases. If you want to be able to manage things "together" at will, then you can use helmfile ( https://github.com/roboll/helmfile )
-
How to Build Software Like an SRE
I agree; helm is too declarative.
Whenever I can, I use helmfile[0] for storing variables for helm since it does add a declarative layer on top of helm.
0 - https://github.com/roboll/helmfile
-
helmfile sync vs helmfile apply
I went through the Helmfile repo Readme to figure out the difference between helmfile sync and helmfile apply. It seems like unlike the apply command, the sync command doesn't do a diff and helm upgrades the hell out of all releases 😃. But from the word sync, you'd expect the command to apply those releases that have been changed. There is also mention of the potential application of helmfile apply to periodically syncing of releases. Why not use helmfile sync for this purpose? Overall, the difference didn't become crystal clear, and I though there could probably be more to it. So, I'm asking.
-
Managing multiple repos
helmfile is something i’ve used in the past for this https://github.com/roboll/helmfile
-
Helm is both "package manager" and "templating engine" - probably the best package manager but horrible template engine
I always felt like dependencies in helm are for very simple non-coupled packages. I many times use Helmfile (https://github.com/roboll/helmfile) to manage dependencies instead of banging my head with vanilla Helm.
-
So I've installed grafana, loki, and prometheus on the personal Kubernetes cluster via Terraform. Now what?
Once you do that, learn to create dynamic helm charts that use go templating and conditionals: https://github.com/roboll/helmfile
What are some alternatives?
Kyverno - Kubernetes Native Policy Management
flux2 - Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
teleport - A WebXR teleport for three.js
cdk8s - Define Kubernetes native apps and abstractions using object-oriented programming
krane - Kubernetes RBAC static analysis & visualisation tool
helmsman - Helm Charts as Code
trivy - Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
kustomize - Customization of kubernetes YAML configurations
checkov - Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.
helm-operator - Successor: https://github.com/fluxcd/helm-controller — The Flux Helm Operator, once upon a time a solution for declarative Helming.
Gravitational Teleport - The easiest, and most secure way to access and protect all of your infrastructure.
terraform - Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.