atlantis
sealed-secrets
atlantis | sealed-secrets | |
---|---|---|
121 | 71 | |
7,319 | 7,147 | |
1.4% | 1.1% | |
9.7 | 9.1 | |
5 days ago | 8 days ago | |
Go | Go | |
GNU General Public License v3.0 or later | 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.
atlantis
-
OpenTofu 1.7.0 is out with State Encryption, Dynamic Provider-defined Functions
None of these are a replacement of Terraform Cloud (recently rebranded to HCP Terraform). For example, when you create a PR, it could affect multiple workspaces. The new experimental version of TFC/TFE (I refuse to call it HCP!) implements Stacks, which is something like a workflow, and links one workspace output to other workspace inputs. None of the open-source solutions, including the paid Digger [0], support this - only the paid one, such as Spacelift [1] (which is the closest to TFC if you ask me). Having a monorepo of Terraform is a common design pattern, so, if I change an embedded module, it could trigger changes it many workspaces. As far as I know, Atlantis [2] can't really help in this case.
By the way, the reason I singled-out Spacelift is due to its quality, and the great Terraform provider it has. Scalr [3], for example, has a really low-quality Terraform provider. I extensively use the hashicorp/tfe provider to manage TFC itself.
[0]: https://digger.dev/
[1]: https://spacelift.io/
[2]: https://www.runatlantis.io/
[3]: https://www.scalr.com/
-
Terramate meets Atlantis 🚀
Atlantis is a pull request automation tool that works well with plain Terraform right away. But what if we're already using Terramate to generate Terraform code?
-
Top Terraform Tools to Know in 2024
Atlantis automates reviewing and deploying Terraform via pull requests, streamlining collaboration and ensuring consistency across Terraform deployments.
-
Stop Squinting at IaC Templates: Preview Diffs for Argo CD, Terraform, and more!
For example, Atlantisgo for Terraform, Zapier’s Kubechecks for Argo CD, Quizlet’s GitHub action all do something similar to this. But a generic, extensible tool for IaC providers doesn’t seem to exist. Additionally, many of them require exposing your Kubernetes cluster or other infrastructure to third-party access, webhooks, etc.
-
Self-service infrastructure as code
Our first attempt was to introduce other engineering teams to Terraform - the Platform team was already using it extensively with Terragrunt, and using Atlantis to automate plan and apply operations in a Git flow to ensure infrastructure was consistent. We'd written modules, with documentation, and an engineer would simply need to raise a PR to use the module and provide the right values, and Atlantis (once the PR was approved by Platform) would go ahead and set it up for them.
-
Seamless Cloud Infrastructure: Integrating Terragrunt and Terraform with AWS
Alternatively, you can look at solutions like Atlantis or spacelift.
-
What is the equivalent of docker-compose for terraform?
Atlantis: https://www.runatlantis.io/
-
Version of terraform binary cli does it include in the container
Looking at the commits at https://github.com/runatlantis/atlantis, it looks like 1.6.5. Am I right?
-
Terraform Cloud Pricing Changes Sticker Shock
We use Atlantis [0] for CI/CD automation of Terraform pull requests to a centralized repository. It's pretty good too, especially for a self-hosted solution. I can't see how Terraform Cloud's costs would be justifiable for us without a custom contract.
[0] https://www.runatlantis.io/
- Atlantis claims exemption from new HashiCorp license
sealed-secrets
-
Introduction to the Kubernetes ecosystem
External-Secrets Operator : A Kubernetes operator that integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret (Alternatives : Vault, SOPS, Sealed Secrets)
-
Show HN: Open-source alternative to HashiCorp/IBM Vault
I like sealed secrets (https://github.com/bitnami-labs/sealed-secrets) a lot. It's like 1Password, but for apps in kubernetes. You only need to secure a private key, and can throw encrypted secrets in a public github repo or anywhere you want.
It's owned by VMware (Broadcom) now, so you have to decide which company you hate more.
-
Deploy Secure Spring Boot Microservices on Amazon EKS Using Terraform and Kubernetes
If you have noticed, you are setting secrets in plain text on the application-configmap.yml file, which is not ideal and is not a best practice for security. The best way to do this securely would be to use AWS Secrets Manager, an external service like HashiCorp Vault, or Sealed Secrets. To learn more about these methods see the blog post Shhhh... Kubernetes Secrets Are Not Really Secret!.
-
Plain text Kubernetes secrets are fine
Yeah documentation is hard and I'm guilty (as a former maintainer of SealedSecrets)
SealedSecrets was designed with "write only" secrets in mind.
Turns out a lot of people need to access the current secrets because they need to update a part of a "composite" secret.
There are two kinds of "composite" secrets, one easy and one harder, but if you don't know how to do it, even the easier is hard:
1. Secret with multiple data "items" (also called keys in K8s Secret jargon but that's confusing when there is encryption involved). I.e. good old "data":{"foo": "....", "bar": "..."}
2. Secrets where data within one item is actually a config file with cleartext and secrets mixed up in one single string (usually some JSON or YAML or TOML)
Case 1 is "easy" to deal with once you realize that sealed secrets files are just text files and you can just manually merge and update encryoted data items. We even created a "merge" and some "raw" encryption APIs to make that process a little less "copy pasta" but it's still hard to have a good UX that works for everyone.
Case 2 is harder. We did implement a data templating feature that allows you to generate a config file via a go-template that keeps the cleartext parts in clear and uses templating directives to inject the secret parts where you want (referencing the encrypted the items)
The main problem with case 2 is that it's undocumented.
The feature landed in 2021:
https://github.com/bitnami-labs/sealed-secrets/pull/580
I noticed that people at my current $dayjob used sealed secrets for years and it took me a while to understand that the reason they hated it was that they didn't know about that fundamental feature.
And how to blame them!? It's still undocumented!
In my defense I spent so much effort before and after I left VMware to lobby so that the project got the necessary staffing so it wouldn't die of bitrot that I didn't have much time left to work on documentation. Which is a bit said and probably just an excuse :-)
That said, I'm happy that the project is alive and the current maintainers are taking care of it against the forces of entropy. Perhaps some doc work would be useful too. Unfortunately I don't have time for now.
- Storing secrets in distributed binaries?
-
Weekly: Questions and advice
This might be OT, and forgive me, but I think one of the best practices for Encrypting and Managing secrets in Kubernetes is to use Sealed Secrets, they allow your secrets to be securely stored in git with the rest of the configuration and yet no one with access to the Git repository will be able to read them. I say this might be OT, because Sealed Secrets are trying to mitigate a different threat, the threat of the secrets at rest somewhere, and not "live in the cluster", where in theory all the ingredients to decrypt the secrets would still live.
-
Want advice on planned evolution: k3os/Longhorn --> Talos/Ceph, plus Consul and Vault
The addition of Consul and Vault gives me a few things. For one, right now I'm handling secrets with a mixture of SOPS and Sealed Secrets. I use Vault in my professional life, and have used both Vault and Consul at my last job. Vault is a beast, so I may as well get better at it; plus its options for secret injection are better.
- Homebrew 4.0.0 release
-
How to Deploy and Scale Strapi on a Kubernetes Cluster 1/2
Use Sealed Secrets Operator.
-
Secret Management in Kubernetes: Approaches, Tools, and Best Practices
sealed-secrets (sealed)
What are some alternatives?
terraform-github-actions - Terraform GitHub Actions
vault-secrets-operator - Create Kubernetes secrets from Vault for a secure GitOps based workflow.
argo-cd - Declarative Continuous Deployment for Kubernetes
sops - Simple and flexible tool for managing secrets
backstage - Backstage is an open platform for building developer portals
Vault - A tool for secrets management, encryption as a service, and privileged access management
terragrunt - Terragrunt is a thin wrapper for Terraform that provides extra tools for working with multiple Terraform modules.
kubernetes-external-secrets - Integrate external secret management systems with Kubernetes
Pulumi - Pulumi - Infrastructure as Code in any programming language. Build infrastructure intuitively on any cloud using familiar languages 🚀
helm-secrets - A helm plugin that help manage secrets with Git workflow and store them anywhere
tfsec - Security scanner for your Terraform code [Moved to: https://github.com/aquasecurity/tfsec]
argocd-vault-plugin - An Argo CD plugin to retrieve secrets from Secret Management tools and inject them into Kubernetes secrets