[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 fc0fc79eb63130d9f0f4bcc66f7a6f17c41d1144
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
      - 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
    All other KeyManager functions are not overridden, and will therefore be
    handled directly by the real backend.
    Change-Id: Ia5316490201c33e23a4206838d5a4fb3dd00f527