Secret manager in Port
complete
David - Port team
The new secret manager will allow saving secrets/credentials/variables in Port in a secure way.
The secrets will be available for reference when controlling the payload of a specific action.
This will allow scenarios such as creating a "Create PagerDuty incident" webhook action that sends an API request to PagerDuty with the relevant PagerDuty secrets.
Gur Shafriri
complete
You can now store secrets and reference them in self service actions, automations and data sources. See docs: https://docs.getport.io/sso-rbac/port-secrets/
A
Albert Luganga
Can we also add local v global secrets. Some secrets should be local to the data source and others usable throughout Port.
Gur Shafriri
in progress
Gur Shafriri
planned
We are now planning to introduce secret management in port that will work with both Ocean saas (https://port.canny.io/ideas/p/support-ocean-integration-hosting-through-port-ocean-saas) and configuring action payload (https://port.canny.io/ideas/p/self-service-actions-controlling-the-payload)
Matt Domko regarding your feedback - you can use the Port Agent for self hosted actions and use the secrets manager you have as part of it. This gives the options needed based on your security needs. What do you think?
David - Port team
open
Matt Domko
I already manage secrets in K8s, Github, AWS Secrets Manager, Azure Key Vault.... maybe just the ability to set the context/identity of a port integration and allow me to reference/use those secrets instead?
Philip Mather
Matt Domko: Would agree, there's at least 3 defacto enterprise grade options for this. Also seems to contradict "Can I deploy Port on-premise?" on https://www.getport.io/try-now??
Matt Domko
If we think about the way self-hosted runners work in github... we could do something similar with port? IE - If I want to expose secrets to port, I deploy a container that is continuously polling for, "what secrets do you want". If port asks for a secret, it will try to get it and return the value.
--- Implementation Idea ---
"Port-AzureKeyVaultProxy-Foo" is a pod deployed in my environment via helm chart. The pod is provisioned with an Azure Identity (either through environs, or another support method) that has access to Foo keyvaults.
When an action needs a secret, I simply select the proxy that contains it, and enter the KeyvaultName and SecretName.
Secret Proxies are simply another DataSource managed through the PortUI.
--- /Idea ---
Access control for secret proxies becomes a problem...