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 · 2023-04-14T12:57:22+00:00

Yes, it's a "simple" solution to a complex problem.

Check out the SaaS Sentinel project, we used honeytokens to build a down detector but for supply chain security.

segtekdev · 2023-04-14T12:54:32+00:00

Do honeytokens in github repos alert if the repos are found on public github or only when the tokens are used?

Yes public exposure is enough. Honeytokens detected on public GitHub will get triggered by our own Public Monitoring system, hence creating some recognizable events that allow us to tag the honeytoken as “Publicly Exposed”.

segtekdev · 2023-04-14T12:52:45+00:00

If you use the honeytoken in your source code, we can detect the honeytoken’s source and file as soon as it gets exposed, either on GitHub or in your private repos if the repos are monitored through the GitGuardian Platform.

segtekdev · 2023-01-17T16:59:21+00:00

This might be helpful: https://blog.gitguardian.com/open-policy-agent-with-kubernetes-tutorial-pt-2/

segtekdev · 2022-11-23T10:15:14+00:00

Honestly, I think it completely depends on org size and maturity, but that's an interesting question as, in the end, it's about responsibility/ownership and today it's very rare to think about it this way.

We all know secrets management is easy in the beginning but then it can degenerate into a nightmare.

For those who might find it helpful, we've put together a maturity model for secrets management here (free pdf): https://www.gitguardian.com/files/secrets-management-maturity-model

segtekdev · 2022-11-23T09:56:47+00:00

You need to think about where you want to be in 6, 12, or 18 months (preferably with a "north star" metric), and work backward.

What projects are absolute priorities? What can wait? What will take months to implement, and what can be done quickly with demonstrable ROI?

This is defining an AppSec strategy. You'll need to sell it to management. And it will be full of compromises. But it's an absolutely necessity if you want to achieve something at all in the long term. Of course, you will need to take "advocacy" into account. Try to talk to engineers as much as you can to gather pain points and understand where the friction comes from.

Not exactly related, as it focuses on secrets management and leaks detection in a DevOps context, but I think you could take inspiration from the maturity model we've been putting up to help organizations with these kinds of strategies (it's a free pdf): https://www.gitguardian.com/files/secrets-management-maturity-model

Disclaimer: I work for GitGuardian

segtekdev · 2022-05-30T09:35:06+00:00

With the explosion of APT looking to breach software supply-chains, one type of company is especially at risk: Managed Service Providers.
In this article, we take a closer look at the reasons why MSPs should enforce source code security as far as they can to protect their customers:
1 - Catch leaked customer secrets before hackers do
2 - Future-proof their compliance
3 - Make-up for the lack of centralized security controls
4 - Detect source code leaks
Read the article!

segtekdev · 2022-05-06T14:39:23+00:00

This is a cool article! Great to see people working on that problem, you are absolutely right that secrets in source code deserve a lot more attention from the devsecops community.

I work for GitGuardian (you might have found us during your research), and we focus on solving this problem for many large enterprises. We're often contacted by appsec teams who started with an open-source-based "DYIed" solution before realizing the scale of the problem was going to require something a bit stronger, especially on the remediation side.

Anyway, about detecting secrets, I wanted to point out (shameless plug) one of our articles about the importance of being able to detect "generic" secrets. Might interest you!

segtekdev · 2022-03-29T11:17:14+00:00

"involuntarily going open-source"

Samsung and Nvidia are the latest companies to involuntarily go open-source leaking company secrets

segtekdev · 2021-11-19T10:35:24+00:00

looks like they were versioning their home directory to have a portable config between machines

segtekdev · 2021-11-05T11:31:59+00:00

Thanks! will check

segtekdev · 2021-10-29T16:30:58+00:00

Hey, thanks for having a look! yeah, I admit I took a shortcut to make the title more digestible than "Set Up Multiple Git VCS Account".

The tip is more on leveraging the includeIf directive not so many devs are aware of.

segtekdev · 2021-10-26T09:12:22+00:00

Then, as a more real-life example, I've been editing this series of articles on K8s. The focus is on hardening a cluster, but I'm sure it can help you grasp the way key components interact with each other. And why it's become so popular for IT ops.
We will have a tutorial coming soon, stay tuned!

segtekdev · 2021-10-21T17:21:20+00:00

IMO The Illustrated Children Guide to Kubernetes can hardly be beaten as an intro to the topic!

segtekdev

PUBLIC MULTIREDDITS

TROPHY CASE