Legacy Key Management

This section provides documentation on the AIStor Key Encryption Service (KES). AIStor KES is a maintained fork of the MinIO KES project under MinIO’s enterprise license.

For new or long-term deployments, consider using the AIStor Key Manager to replace KES.

Migrate from KES CE to AIStor KES on Linux

The following procedure describes how to migrate from the deprecated KES Community Edition (KES CE) to the latest stable AIStor KES releases. This procedure assumes an existing KES CE cluster running latest available release.

Migration does not require modifying your existing AIStor Object Store deployments. However, the procedure requires restarting the KES nodes and therefore may have a brief period of time where one or more nodes cannot respond to requests. Client applications typically transparently retry requests and therefore should have little or no disruption outside of increased log activity.

  1. Download the latest AIStor KES release for your OS and system architecture.

    OS ARCH Binary
    linux amd64 linux-amd64
    linux arm64 linux-arm64

    Download the binary using your preferred CLI utility. The following example downloads the ARM64 binary using curl and sets it as executable using chmod:

    curl -sSL --tlsv1.2 'https://dl.min.io/aistor/kes/release/linux-amd64/kes' -o ./kes
    
    chmod +x ./kes
    

    Repeat this step on each node in your KES cluster.

  2. Replace the KES CE binary on each node in your KES cluster.

    Backup the existing KES CE binary.

    mv /usr/local/bin/kes /usr/local/bin/kes.bak
    

    Move the downloaded AIStor KES binary to /usr/local/bin/kes.

    mv ./kes /usr/local/bin/kes
    

    Verify that the new KES binary is installed correctly.

    kes --version
    
  3. Add your SUBNET license to the KES environment file

    Log into SUBNET and select the License button in the Deployments view to retrieve your license key.

    Open the KES systemd file, typically located at /etc/systemd/system/kes.service. Modify the ExecStart line to include the --license SUBNET-LICENSE parameter as in the following example:

    ExecStart=/usr/local/bin/kes server --config-dir /etc/kes/config.yaml --license SUBNET-LICENSE
    

    Save the file and run systemctl daemon-reload to reload the systemd configuration.

  4. Restart the KES service on each node in your KES cluster.

    Restart all nodes simultaneously using a tool like pssh or pdsh. This minimizes the time window in which nodes may run different KES versions.

    Restart the KES service to apply the changes.

    systemctl restart kes
    

    Verify that the KES service is running correctly.

    systemctl status kes
    

    Check the KES logs for any errors.

    journalctl -u kes -f
    

Any AIStor Object Store resources previously using KES CE should continue to function without requiring any changes. Monitor system logs to validate normal functionality.

Migrate from KES CE to AIStor KES on Kubernetes

You can migrate from KES CE to AIStor CE by updating the image reference in your KES deployment manifest.

For Kubernetes deployments using the MinIO Operator, you must first migrate to use the AIStor Operator and associated resources. Open a SUBNET support ticket to request assistance with this migration.

For existing object store deployments using the AIStor Operator Helm charts, you can update the KES image reference in the object store Helm chart values.yaml file. Modify the kes.image.repository and kes.image.tag fields to pull the latest AIStor KES image. For example:

kes:
  image:
    repository: docker.io/aistor/kes
    tag: latest
    pullPolicy: IfNotPresent

Use helm upgrade to apply the changes to the object store. Replace the OBJECT_STORE_NAMESPACE and OBJECT_STORE_NAME with the namespace and release name of the target object store.

helm upgrade -n OBJECT_STORE_NAMESPACE OBJECT_STORE_NAME aistor/aistor-objectstore -f values.yaml

Any AIStor Object Store resources previously using KES CE should continue to function without requiring any changes. Monitor the deployment and pod logs to validate normal functionality. You can also use kubectl get all -n OBJECT_STORE_NAMESPACE to monitor the status of the object store resources and ensure that the KES pods restarted and updated successfully.

See the AIStor Object Store documentation for more information the Object Store Helm chart.