Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backend 500 error in some scenarios when using static encryption keys #3513

Open
marat2509 opened this issue Mar 9, 2025 · 3 comments
Open
Labels
bug this needs to be fixed community

Comments

@marat2509
Copy link

marat2509 commented Mar 9, 2025

Expected Behavior

It is expected that when using MINIO_KMS_SECRET_KEY or MINIO_KMS_SECRET_KEY_FILE:

  • There will be no error when opening /kms/status in WebUI (Monitoring -> Encryption)
  • That the key creation button in /kms/keys in WebUI (Encryption) will be inactive with the message Unavailable due to static key usage.

Current Behavior

  • The /kms/status tab in the WebUI (Monitoring -> Encryption) displays the error We encountered an internal error, please try again. (requested functionality is not supported) (probably a problem on the backend side)

    Image

  • The Create Key button in the /kms/keys tab of the WebUI (Encryption) is active, but when trying to create a key an error We encountered an internal error, please try again. (requested functionality is not supported)

    Image

Part of logs, when opening the /kms/status tab in WebUI (Monitoring -> Encryption)

[REQUEST kmsAPIHandlers.KMSStatus] [2025-03-09T12:01:14.960] [Client IP: {REDACTED}]
GET /minio/kms/v1/status
Proto: HTTP/1.1
Host: 127.0.0.1:9000
Content-Length: 0
User-Agent: MinIO (linux; amd64) madmin-go/3.0.70 MinIO Console/(dev)
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Date: 20250309T120114Z
X-Amz-Security-Token: {REDACTED}
X-Forwarded-For: {REDACTED}
Authorization: AWS4-HMAC-SHA256 Credential={REDACTED}, SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature={REDACTED}

[RESPONSE] [2025-03-09T12:01:14.960] [ Duration 75µs TTFB 72.547µs ↑ 114 B  ↓ 263 B ]
200 OK
Accept-Ranges: bytes
Content-Type: application/json
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Amz-Bucket-Region: {REDACTED}
X-Content-Type-Options: nosniff
Content-Length: 263
Server: MinIO
Vary: Origin,Accept-Encoding
X-Amz-Id-2: {REDACTED}
X-Amz-Request-Id: {REDACTED}
X-Xss-Protection: 1; mode=block

{
    "name": "MinIO builtin",
    "default-key-id": "default",
    "endpoints": {
        "127.0.0.1": "online"
    },
    "state": {
        "Version": "",
        "KeyStoreLatency": 0,
        "KeyStoreReachable": false,
        "KeystoreAvailable": false,
        "OS": "",
        "Arch": "",
        "UpTime": 0,
        "CPUs": 0,
        "UsableCPUs": 0,
        "HeapAlloc": 0,
        "StackAlloc": 0
    }
}

Possible Solution

  • On the backend side, do not return an error for /api/v1/kms/apis if a static key is used, but return an empty response (or any other response reflecting the static keys used), which will be correctly handled by the frontend
  • On the backend side, disable key creation via /api/v1/kms/keys, and make the button inactive in the frontend

Steps to Reproduce (for bugs)

Deploy MinIO (for example via docker-compose) with MINIO_KMS_SECRET_KEY variable

Context

It is expected that there will be no backend 500 error when using static keys, and that unnecessary and unworkable (which is correct) encryption key creation functionality will not be available to the end user

Regression

Is this issue a regression? No

Your Environment

  • Version used (minio --version): RELEASE.2025-02-28T09-55-16Z (go1.23.6 linux/amd64)

  • Server setup and configuration:

    compose.yaml

    name: minio
    services:
        minio:
            ports:
                - 9000:9000
                - 9001:9001
            volumes:
                - ./data:/data
            environment:
                - MINIO_VOLUMES="/data"
                - MINIO_KMS_SECRET_KEY=default:7CSnK3oq0aW0wVkvJqz0BxEeAnfV6EWvSoJRqULuf9g=
            container_name: minio
            image: minio/minio
            command: "server --address :9000 --console-address :9001"
    
  • Operating System and version (uname -a): Linux node1 4.4.0-210-generic #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 Linux

@harshavardhana harshavardhana transferred this issue from minio/minio Mar 10, 2025
@harshavardhana
Copy link
Member

This is a UI issue, moving it here.

@cesnietor cesnietor added bug this needs to be fixed and removed triage labels Mar 10, 2025
@cesnietor
Copy link
Collaborator

cesnietor commented Mar 10, 2025

We need replicate and have a better way to log the issue on the backend so we can debug better.
On the UI we need(possibly) to disable this if the values are set as env variables.
Still needs more analysis.

@marat2509
Copy link
Author

What is funny, for play.min.io:9443 apparently also used MINIO_KMS_SECRET_KEY/MINIO_KMS_SECRET_KEY_FILE, and this bug is also present there 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug this needs to be fixed community
Projects
None yet
Development

No branches or pull requests

3 participants