etcd VS Vault

While exploring popular projects such as etcd and especially traefik, I noticed a violation of the principle that states "interfaces should belong to the package that uses values of the interface type, not the package that implements those values." For example, Here we can see that ManagerFactory import Registry interface that placed here and implementations of this interface in the same package, which violates the aforementioned principle. Even if the interface is simply a specification, it should still be defined on the consumer side. Is it considered bad practice to follow what traefik does in this case or I doesn't understand somthing? P.S. I'm newcomer, so sorry if it's silly question.

In case of data sensitivity, you can enable the encrypted communication function of etcd for encrypted data transmission. Refer to the sample script provided by the etcd project.

Step 0: You have a strong grasp on who uses the tool/product/service and for what purpose. That can take weeks, months, or years depending on the specific project you're contributing to. A little NodeJS module? Probably closer to days. etcd? Probably closer to months/years.

etcd is not secure - etcd is where Kubernetes secrets are stored. Though etcd is a distributed key/value store with great performance, it lacks key features when it comes to handling sensitive data such as audit log, key rotation, and encryption of key.

You know how Kubernetes is absolutely blowing up? Well there's one piece of technology that it all depends on -- etcd.

FROM quay.io/coreos/etcd:v3.5.0 as etcd FROM alpine:3.17 RUN apk add --no-cache tar # Taken from https://github.com/etcd-io/etcd/blob/main/Dockerfile-release.amd64 COPY --from=etcd /usr/local/bin/etcd /usr/local/bin/ COPY --from=etcd /usr/local/bin/etcdctl /usr/local/bin/ COPY --from=etcd /usr/local/bin/etcdutl /usr/local/bin/ COPY --from=etcd /etc/nsswitch.conf /etc/nsswitch.conf CMD ["/usr/local/bin/etcd"]

Service registry and discovery etcd, consul, nacos

Yes, Kubernetes, in fact, relies on a number of other free and open source software packages. As a base, it relies on the Docker container runtime and the CoreOS Linux distribution, and it utilizes other open source projects for a number of its components, such as etcd for distributed key-value storage. The tool's core and control plane are both built in GO programming language, making it a completely Go-based application. Kubernetes itself is an open source project and has been used as a building block for other open source projects.

APISIX stores its configuration in etcd

Next, review deployment complexity such as DB-less versus database-backed deployments. For example, Kong does require running Cassandra or Postgres. Apigee requires Cassandra, Zookeeper, and Postgres to run, while other solutions like Express Gateway and Tyk only require Redis. Apache APISIX uses etcd as its data store, it stores and manages routing-related and plugin-related configurations in etcd in the Data Plane.

I am planning to run about 4-5 validator instances at once with these being full archive nodes (since the same storage is used, and I think that a number of SSD's is a good investment if I have full introspective on transactions), at the same time host a Otterscan instance, and also possibly, but unrelated (although mentioning to give you the full spec) a personal HashiCorp Vault instance.

Note that dumping the Vault's process memory is beyond hashicorp/Vault's threat model. See: https://github.com/hashicorp/vault/issues/1446#issuecomment-...

Note that dumping the Vault's process memory is beyond hashicorp/Vault's threat model. See: https://github.com/hashicorp/vault/issues/1446#issuecomment-...

I'm bringing this up because the circleCI blogpost says that the attacker did memory-dump encryption keys from a running process. See https://circleci.com/blog/jan-4-2023-incident-report/

So even if they were using hashicorp/vault, the attacker could probably still have been able to mem-dump vault's process.

This script helps me switch vault contexts for pulling secrets in different environments like staging and production.

Another site which uses the same template https://www.vaultproject.io

Sealed Secrets are a great starting point for securing secrets, but there is an even better way. Using the External Secrets Operator (ESO) and an external secret management system like HashiCorp Vault, AWS Secrets Manager, Google Secrets Manager, or Azure Key Vault. While this is a bit more involved to set up, it is a better approach if you use a cloud provider to host your Kubernetes cluster. ESO supports many such secret managers and watches for changes to external secret stores, and keeps Kubernetes secrets in sync.

Everyone I push Vault to these days ends up loving it: BUT end up hating the ACL language along with the still present lack of official search functionality. It's a LITTLE technical for less "IT Focused" industries though; and the lack of a "fancy gui" has it's own issues.

Vault.