[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Openstack-security] [openstack/castellan] SecurityImpact review request change openstack%2Fcastellan~master~Ia5316490201c33e23a4206838d5a4fb3dd00f527

Hi, I'd like you to take a look at this patch for potential

commit 5ba0837b3b3cb20ee0e31604ee97e3c4a284990f
Author: Alan Bishop <abishop at redhat.com>
Date:   Tue Oct 24 14:53:36 2017 +0000

    Support handling legacy all-zeros key ID
    This patch addresses a specific use case, where a user has encrypted volumes
    based on the fixed_key used by Cinder's and Nova's ConfKeyManager. The user
    wishes to switch to Barbican, but existing volumes must continue to function
    during the migration period.
    The code conditionally adds a shim around the backend KeyManager when both
    of these conditions are met:
    1) The configuration contains a fixed_key value. This essentially signals
       the ConfKeyManager has been in use at one time
    2) The current backend is *not* the ConfKeyManager
    When the shim is active, a MigrationKeyManager class is dynamically created
    that extends the backend's KeyManager class. The MigrationKeyManager exists
    solely to override two functions:
    o The KeyManager.get() function detects requests for the secret associated
      with the fixed_key, which is identified by an all-zeros key ID.
      - Requests for the all-zeros key ID are handled by mimicing the
        ConfKeyManager's response, which is a secret derived from the fixed_key.
      - Requests for any other key ID are passed on to the real backend.
    o The KeyManager.delete() function is similar:
      - Requests to delete the all-zeros key ID are essentially ignored, just as
        is done by the ConfKeyManager.
      - Requests to delete any other key ID are passed on to the real backend.
    All other KeyManager functions are not overridden, and will therefore be
    handled directly by the real backend.
    Change-Id: Ia5316490201c33e23a4206838d5a4fb3dd00f527