Waiting for input...
Star SPIKE on GitHub

ADR-0018: Administrative Access to SPIKE


  • Status: accepted
  • Data: 2025-02-20
  • Tags: Security, Administrative-Access, SPIFFE, IDM, DR

Context

SPIKE requires a robust and secure administrative access model to balance operational flexibility, security, and auditability. To achieve this, SPIKE defines three predefined roles for emergency Disaster Recovery (DR) and superadmin access, while delegating named administrative access to an external identity management system.

Decision

Role-Based Administrative Access

Administrative access in SPIKE is granted using specific SPIFFE IDs:

*spiffe://$trustRoot/spike/pilot/role/superuser - Super Admin: Can perform all administrative tasks except recovery or restore operations. *spiffe://$trustRoot/spike/pilot/role/recover - Recovery User: Can only recover the root key shards to the local file system. *spiffe://$trustRoot/spike/pilot/role/restore - Restore User: Can only restore the root key by providing one shard at a time.

This role separation ensures that:

  • Different users can have distinct operational responsibilities. For example, an operator responsible for system restoration cannot modify access policies for secrets.

  • The separation enhances auditability, allowing clear tracking of actions taken by different roles.

  • Additionally:

  • Once the system is initialized, accidental re-initialization is prevented.

  • In emergencies, an out-of-band script can be used to perform a factory reset of SPIKE.

Multi-Admin Support via External Identity Management

Beyond the three predefined roles (superuser, recover, restore), named admin access to SPIKE will be managed through an external identity provider, such as an OIDC (OpenID Connect) provider.

Here’s the reasoning:

  • SPIKE focuses on secure and efficient secret storage, not authentication.
  • Access control and identity management are better delegated to established identity standards like OIDC.
  • This approach ensures compatibility with enterprise authentication policies and simplifies integration with existing IAM solutions.

Consequences

  • Security: The predefined SPIFFE-based roles provide a minimal attack surface for core administrative functions, while OIDC integration ensures scalability and proper identity management.
  • Auditability: Separation of concerns ensures that different roles have clearly defined privileges, improving traceability and compliance.
  • Flexibility: Organizations can define additional admin roles through their preferred external identity provider without modifying SPIKE’s core architecture.

Alternatives Considered

  1. Fully SPIFFE-Based Admin Management
    • Rejected due to scalability concerns. Managing multiple administrators directly within SPIKE would introduce unnecessary complexity.
  2. No Role Separation
    • Rejected for security and compliance reasons. A single admin role would lack the necessary granularity for controlled recovery and restore operations.