Skip to main content

Security

Security is where AstroPulse starts, not a feature added later. AstroPulse manages production in your own cloud, so it is built to hold as little as possible, to give every part only the access it needs, and to make every action accountable. Your workloads and data stay in your accounts.

Each layer stands on its own, so getting past one does not open the next:

  • No standing keys. AstroPulse reaches your cloud with short-lived access you can revoke at any time, and add-ons act as your cluster's own workload identity. There is no long-lived key of yours to steal for the clouds AstroPulse manages.
  • Least privilege. Each identity AstroPulse uses in your cloud, and each add-on's, can do only its own job in one place.
  • Isolated services. AstroPulse's own services run with network policies, so each one can talk only to what it needs.
  • Secrets that cannot be read back. The few credentials AstroPulse keeps are encrypted, and no console page, command or API ever returns one.
  • Every request checked, every change recorded. Each call is authenticated and held to the caller's role in one organization; each change is checked with a dry run before it is made and written to the audit log.

Your cloud accounts: no keys to hand over​

Connecting a cloud account creates trust, not a credential:

  • Amazon Web Services. The Connect step creates a role in your account that trusts only AstroPulse and requires an external ID. AstroPulse uses it in short sessions, never with a stored key.
  • Google Cloud. Workload identity federation: AstroPulse acts as a service account in your project with short-lived tokens. No key file exists.
  • Microsoft Azure. A federated credential, to which you grant roles in your subscription. Tokens are short-lived.

You can see, narrow or remove that trust in your own cloud at any time.

Add-ons: one identity each, least privilege​

An add-on that calls your cloud, such as DNS Automation, Certificates or Vulnerability Scanning, runs as one Kubernetes service account that your cloud trusts for exactly what that add-on does: change records in one DNS zone, or pull images from your registry. There is no key to store, leak or rotate. Where you choose a Kubernetes Secret instead, it stays in your cluster and AstroPulse never reads it. See Cloud access for add-ons.

Your clusters: connected from the inside​

Each cluster runs the Astro Agent, which connects out to AstroPulse over mutual TLS:

  • The agent makes its own private key inside the cluster, and the key never leaves it. AstroPulse only signs a request for its certificate.
  • The certificate is renewed automatically before it expires, and a registration token works once and only for minutes.
  • A cluster you register needs no inbound port: its Kubernetes API does not have to be reachable from the internet.

What the agent sends about your workloads is summaries, such as cost and usage per application: not Pod names, images, logs or environment.

Secrets you give AstroPulse​

A Hugging Face token, a registry token or a Slack webhook goes into AstroPulse's credential store, encrypted at rest:

  • No API, console page or command returns a stored secret. You see only that one is saved, and what kind.
  • Access is denied by default and granted per service: a cluster's agent can reach only its own cluster's credentials, and Nova has no access at all.

People, keys and service accounts​

  • Roles. Every request is checked against the caller's role in one organization. Nothing crosses organizations.
  • API keys are never stored in a form that can be read back, are shown once when created, and expire after 24 hours by default. A revoked key keeps its record with who revoked it and why. See API keys.
  • Automation signs in as a service account with its own role, so it keeps working when people leave and its actions are recorded under its own name.
  • Every change is recorded: who, what, when, from which address and client, in the audit log.

Nova​

Nova acts through the same API, under your organization's guardrails: it asks before it changes production, and an owner can stop every Nova write at once. See Guardrails and approvals.

The credentials you give Nova's skills, such as an API key or an OAuth token for a tool you connect, are encrypted with keys held in a key-management service, and Nova's API never returns them: it only says that a skill has credentials.

Before anything changes​

Every create, update, install and deploy runs a dry run first: the exact change is checked against your cluster and cloud before anything is applied, and a refusal says why in plain words. New clusters can also wait for an owner's approval.

Next​