Connections
A connection holds the credential an action step sends with. Steps reference a connection by name and never contain a token, so a workflow can be edited, exported or shared without carrying a secret.
Manage them under Workflows → Connections.
How credentials are handled
Secrets are write-only: once saved, a credential is never sent back to the browser. Editing a connection shows a masked summary until you choose to replace the value.
Sending happens inside KubeSense's API, not the execution engine — the engine renders a payload, names a connection, and asks the API to deliver it. Only the API can decrypt a credential, so the component that runs user-authored workflows never holds one.
Slack
A Slack connection reuses the workspace you already connected for alert notification channels. The bot token lives once per workspace, so there is no second OAuth flow and no second copy of the token to rotate.
Pick the workspace on the connection, then pick the channel on each Slack step.
The bot must be in the channel it posts to — invite it with /invite @kubesense in Slack, otherwise the step fails with not_in_channel.
HTTP
For Jira, PagerDuty, CI systems, or your own services.
| Auth mode | Sends |
|---|---|
| Bearer | Authorization: Bearer <token> |
| Basic | Authorization: Basic <encoded> |
| Custom header | A header name you choose, e.g. X-Api-Key |
| None | No credential |
A step cannot override the header its connection provides. Setting Authorization on a step whose connection also sets it is rejected outright rather than silently resolved, so a workflow author can't swap a stored credential for their own.
Limiting where a connection can reach
Two independent restrictions, both worth setting:
Host allowlist — the only hosts this connection may call. Requests anywhere else are rejected server-side, templated URLs included.
Base URL — pins the connection to one origin and path prefix, e.g. https://jira.internal/rest/api. This is the stronger of the two: a host allowlist still permits any path on that host, and any path is enough to point a stored credential somewhere it was never meant to go. Redirects are re-checked against the pin, so a permitted host cannot redirect its way out.
Leave the base URL empty for no pin.
info: Requests to loopback and link-local addresses are always refused, including through a hostname that resolves to one. Private networks are refused unless your deployment enables them deliberately — so an internal Jira needs a configuration change, not just a connection.
Deleting a connection
A connection in use is not silently removable: the list shows how many workflows reference it, and publishing a workflow whose connection has since been deleted is refused with a message naming it — rather than letting it fail later at the moment it was supposed to send.