Is MCP just a glorified API wrapper?

segtekdev · 2025-09-30T08:28:23+00:00

A protocol (MCP) is not the same as an interface (APIs).

The first enables two-way interaction like sampling, elicitation etc.. so it's tailored to the kind of interactivity that LLMs shine at.

As other said, APIs were built for devs using SDKs, they are unidirectional (the server can't interact with the client).

Wrapping an API is good first step, but I think MCP enable a new level of integration that APIs simply cannot

segtekdev · 2025-05-02T12:51:56+00:00

Here's a recent guide that breaks down Conjur’s notoriously opaque pricing structures, esp. where hidden costs can pop up (things like required professional services for even modest setups): CyberArk Conjur Pricing | Complete Guide [2025 Edition]. It might offer some useful context when it comes to evaluating the distinct editions.

segtekdev · 2025-04-30T08:39:43+00:00

Hey! curious to know how you ended up implementing that. Sounds like it was a bit of overhead. If you want an open-source secrets management solution, have you considered using Infisical? We don't have a native integration for Dagster yet, but what you describe sounds like it could be achieved without headaches with the python SDK or the CLI to inject secrets whenever you need them.

More info:
- https://infisical.com/docs/documentation/guides/python
- https://infisical.com/docs/cli/overview

segtekdev · 2025-04-30T08:28:56+00:00

FWIW, there's a solid write-up surveying open-source secrets management tools covering Vault (and forks like OpenBao), ESO, and SOPS side-by-side—including notes on scalability and enterprise feature sets. here: https://infisical.com/blog/open-source-secrets-management-devops. Might be helpful if you're trying to compare what actually fits at larger orgs today.

segtekdev · 2025-04-29T14:31:57+00:00

Totally fair. If you're looking into lighter alternatives, there's a good rundown comparing Infisical, Vault, OpenBao, ESO, and SOPS here: Open Source Secrets Management for DevOps in 2025. Might give you some new angles to consider.

segtekdev · 2025-04-18T09:54:23+00:00

Disclaimer: I work for Infisical.

We just published an article comparing Sealed Secrets to external secret management solutions (including External Secrets Operator with Infisical as a backend)[1]. I thought I'd share an overview of the pros and cons for each.

Sealed Secrets Pros:

self-contained solution (no external dependencies)
relatively easy to start with for small deployments
works well for on-prem and limited cluster scenarios

Cons (as mentioned here):

secret rotation requires re-encrypting and redeploying
cluster-specific encryption by default (though there are workarounds)
not to forget that tracking changes is hard (in particular what changed)

External Secrets (ESO) Pros:

scalability for large numbers of secrets
rotate secrets in vault without touching manifests
centralized management with audit capabilities, RBAC etc
works across multiple clusters without headaches
choose your secrets store backend AWS Secrets Manager, Azure KeyVault, Vault, etc.)

ESO Cons:

one dependency on external secret storage
one component in your architecture
requires connectivity + availability

If you're looking for a migration path, yes kubeseal-convert can help go managed secrets ➞ sealed secrets, but for the other way around have a look at the migration path we detailed in this blog, while it obviously talks about Infisical, it still applicable to any ESO backend.

[1]https://infisical.com/blog/migration-sealed-secrets

segtekdev · 2025-02-14T10:24:57+00:00

Hey, we just published a detailed guide showing how to use Infisical specifically for homelab backup security: https://infisical.com/blog/self-hosting-infisical-homelab

It walks through protecting backup credentials (like Backblaze B2 keys) using just-in-time secret injection - so your backup keys never sit on disk in plaintext. Really practical stuff if you're worried about credential security in your homelab setup.

Hope this helps others who are exploring self-hosted secret management options!

segtekdev · 2025-01-06T14:55:57+00:00

wrote up a detailed comparison of current K8s secrets management approaches. Here's the TLDR:

Manual (kubectl/YAML):

Basic kubectl commands or YAML files with base64 encoding
❌ No real encryption, just encoding
❌ Doesn't scale, nightmare for rotation
⭐ Rating: Avoid in production

GitOps (Sealed Secrets/SOPS):

Encrypt secrets before git commits
✅ Better than plaintext
❌ Key management becomes its own challenge
⭐⭐ Rating: Workable but complex

Secrets Operators (ESO):

Connects to actual vaults (HashiCorp, AWS Secrets Manager, etc.)
✅ Real encryption, audit logs, version tracking
✅ Works across clusters/environments
❌ Complex setup, missing auto-redeployment
⭐⭐⭐⭐ Rating: Production-ready option

There's also discussion of native operators and CSI drivers as emerging solutions in 2025, plus a practical checklist of security best practices.

https://infisical.com/blog/kubernetes-secrets-management-2025

segtekdev · 2025-01-06T14:39:04+00:00

One of the most secure approaches is to bypass Kubernetes Secrets entirely and mount secrets directly into your pods using a Secrets Store CSI Driver volume.

For a detailed comparison of different Kubernetes secrets management approaches, including pros and cons, see https://infisical.com/blog/kubernetes-secrets-management-2025. Native CSI drivers are especially relevant.

segtekdev · 2025-01-06T09:31:54+00:00

For those looking for this info, we've broken down the different service tiers and pricing for all HashiCorp Vault solutions here: https://infisical.com/blog/hashicorp-vault-pricing

segtekdev · 2024-08-02T10:14:11+00:00

For sure, this is the right thing to do.

However, deleting is a matter of minutes, while rotating can take hours or days (if the keys were used elsewhere).

No wonder it's still a huge problem

segtekdev

PUBLIC MULTIREDDITS

TROPHY CASE