Just saw the announcement for the Appgate+ bundle. Merging their SDP, risk-based authentication, and client into a single "suite" feels like a natural evolution, but as someone who lives in the world of secrets and policy-as-code, I'm inherently skeptical of bundled "solutions." They often hide complexity instead of reducing it.
My main question is about the operational reality. Does this new bundle actually simplify the secret and policy lifecycle, or does it just put a unified dashboard on top of three distinct systems? For example, when they say "unified policy," does that mean I can define a single resource entitlement in one place, using a declarative format, and have it govern network access *and* application access? Or am I still managing separate policy engines that happen to share a UI?
From a vault perspective, I'm curious how the integrated risk scoring works with external secrets. If the system needs a risk score from an external source (like a threat intel feed), is that secret (API key) managed internally, or can it integrate with a proper external secrets manager like HashiCorp Vault? I'd hate to see this become another siloed credential store.
```hcl
# What I *don't* want: another proprietary config.
appgate_policy "legacy" {
rule = "user_group == 'contractors' && ip_location != 'high_risk'"
secret_key = "hardcoded_threatfeed_apikey" # 🤮
}
# What I'd hope for: externalized secrets and clear inputs.
resource "appgate_entitlement" "secure_access" {
name = "db_access"
condition = <<-EOT
user.in_group("contractors") &&
risk.score < ${var.threshold} && # Score from external system
threatfeed.api_key = vault("secret/threatfeed/key") # Secret from vault
EOT
}
```
So, has anyone gotten hands-on with the actual bundle? Is the policy framework truly unified and exportable, or is it marketing fluff around the same connected products? Specifically, how does it handle secrets for its own extended integrations?
Encrypt all the things.
You're right to be skeptical. It's usually a unified dashboard, not a unified engine.
Their docs mention declarative policy import/export, but it's for the whole bundle config, not individual cross-product rules. You still have an SDP policy engine and an app access policy engine. They just happen to ingest from the same file.
For your second point, the risk engine can pull from external APIs. The API key for that can be stored in their internal credential manager. They claim a plugin model for external vaults, but I've only seen that for user secrets, not for the system's own operational secrets. So yes, it often becomes another siloed store.
null