DOCSEARCHbyAlgolia
Submit Docs

OpenStack Barbican

repository·master·Indexed 42 days ago

https://github.com/openstack/barbican

An OpenStack project providing a REST API for the secure storage, management, and provisioning of secrets, including symmetric keys, asymmetric keys, and raw data. It features secret containers (Generic, Certificate, and RSA), an Orders API for asynchronous secret generation, and project-based quota management for resources like secrets, containers, and consumers.

Tokens
59.6K
Snippets
195
Records
270
Agent score
53%

What's inside Barbican

  1. Overview of the Barbican Key Manager service

    master

    Barbican is the OpenStack Key Manager service designed for the secure storage, provisioning, and management of secret data. It is used to manage various types of keying material, including:

    • Symmetric keys
    • Asymmetric keys
    • Certificates
    • Raw binary data

    This service is intended to be used within a working OpenStack environment.

  3. Overview of Barbican

    master
    Barbican is a REST API designed for the secure storage, provisioning, and management of secrets. It is intended for use in various environments, including large ephemeral Clouds. It provides a centralized secret store that can distribute keying material to different types of deployments.

  4. Understand the Barbican project structure

    master

    The Barbican repository is organized into several key directories that separate the REST API, administrative commands, core logic, and plugin interfaces. Understanding this structure helps in locating specific components for integration or extension:

    Core Python Source (barbican/)

    • api/: Contains the REST API implementation.
      • controllers/: Pecan-based controllers that handle incoming REST requests.
      • middleware/: Business logic used to process REST requests.
    • cmd/: Source files for Barbican administrative commands.
    • common/: Shared modules used across the project.
    • model/: SQLAlchemy-based database model classes.
    • plugin/: Logic for managing plugin interfaces and look-ups.
      • resources.py: Manages interactions with plugins.
      • crypto/: Logic and plugins for Hardware Security Modules (HSM).
      • interface/: Interface classes for the Certificate manager and Secret store.
    • queue/: Interfaces for the task queue.
      • client.py: Used by clients to publish tasks to the queue.
      • server.py: Runs the worker service that responds to enqueued tasks.
    • tasks/: Implementations and controllers related to worker tasks.
    • tests/: Unit tests for the Barbican components.

    Deployment and Configuration

    • bin/: Start-up scripts for Barbican nodes.
    • etc/barbican/: Directory containing configuration files.
    • devstack/: DevStack plugin, gate configurations, and Vagrantfile for DevStack VM installation.
    • functionaltests/: Functional tests for the Barbican service.

  5. Key Manager service overview

    master

    Barbican is an OpenStack Key Manager service designed for the secure storage, provisioning, and management of secrets, including passwords and encryption keys. It is composed of three primary service components:

    • barbican-api: The entry point for users and services. It provides an OpenStack-native RESTful API used to provision and manage Barbican secrets.
    • barbican-worker: The backend processing component. It provides an OpenStack RPC interface that communicates with barbican-api and consumes messages from the Barbican message queue to fulfill secret management orders.
    • barbican-keystone-listener: A maintenance component that listens to messages from the Keystone notification service. Its primary role is to manage the representation of Keystone projects within the Barbican database, specifically handling cleanup when projects are deleted.

  6. What is a Barbican Secret?

    master

    A secret is a singular item stored within Barbican. It is used to securely store keying material and sensitive data. Common use cases include:

    • Private Keys
    • Certificates
    • Passwords
    • SSH Keys

    Barbican supports various payload_content_type values to handle different types of data securely.

  7. What is a Consumer in Barbican?

    master
    A consumer is an entity registered as an interested party for a specific container. By registering as a consumer, an entity can be notified before the associated container is deleted. All registered consumers for a container can be retrieved via a GET request to the {container_ref}/consumers endpoint.

  8. How Dogtag interacts with Barbican

    master

    Barbican can use Dogtag as a backend for certificate management and secret storage through two specific plugins:

    1. Dogtag CA Plugin: Uses the Dogtag Certificate Authority (CA) subsystem to issue, renew, and revoke certificates. It acts as a private CA backend for Barbican.
    2. Dogtag KRA Plugin: Uses the Dogtag Key Recovery Agent (KRA) subsystem to securely store secrets. Secrets are encrypted by storage keys stored in either a software NSS database or an HSM.

    To use these features, you must set up a Dogtag instance containing both a CA and a KRA and then configure Barbican to communicate with them using trusted agent credentials.

  9. How Barbican's overall architecture works

    master

    Barbican follows a distributed architecture designed for scalability and asynchronous processing. The system is composed of three main layers:

    1. API Nodes: These handle incoming REST requests via a WSGI server. Requests that can be completed synchronously (like GET requests) interact with the database directly.
    2. Queue & Worker Nodes: For requests requiring asynchronous processing (such as interacting with third-party Certificate Authorities), the API node places a task in a queue. Worker nodes then pick up these tasks from the queue to execute them.
    3. Database/Datastore: A central repository for secured information. The architecture supports database replication across data centers for region-agnostic storage.

    This design allows for auto-scaling by adding or removing API and worker nodes as needed.

  10. Understand Barbican plugin statuses

    master

    Plugins in Barbican are categorized into three statuses which define the level of support provided by the OpenStack Barbican Team:

    StatusDescription
    stableFully supported by the OpenStack Barbican Team.
    experimentalIntended for support, but may lack features, may not be fully tested, and may occasionally break.
    out-of-treeNo formal support is provided; the plugin may be removed in a future release.

  11. How Barbican's plugin architecture works

    master

    Barbican uses an abstract class pattern to allow custom implementations of features like secret storage, secret generation, and event handling.

    Key Concepts:

    • Barbican Core: The central logic that manages the lifecycle of a request. It handles persisting required information on the plugin's behalf, meaning plugins typically do not interact with Barbican's data model directly.
    • Discovery via supports(): Barbican core invokes a variation of the plugin's supports() method to determine if the plugin is capable of performing a requested action.
    • Execution: Once a supporting plugin is selected, Barbican core invokes one or more specific methods on the plugin instance to complete the action.

    This architecture allows operators to swap implementations (e.g., using a corporate database instead of the default) to suit their specific cloud environment.