[Bug report] Sensitive S3 secret key exposed in catalog properties when using HadoopFileIO

[vanphuoc3012]

Version

main branch

Describe what's wrong

Description:
When creating an Iceberg catalog configured with HadoopFileIO and the s3-secret-key credential provider, the S3 secret key is returned in plaintext when calling getCatalog or listCatalogs (with details). Secrets should be masked/hidden in API responses.

Impact:
Security concern — S3 secret keys are exposed to any user or client with permission to view catalog details.

Environment:

• Gravitino version: 1.3.0
• Catalog provider: lakehouse-iceberg
• Catalog backend: hive
• File IO: org.apache.iceberg.hadoop.HadoopFileIO
• Credential provider: s3-secret-key

Error message and/or stacktrace

Expected Behavior:
Sensitive credentials (e.g., gravitino.bypass.fs.s3a.secret.key) should be masked or omitted from the catalog properties returned by the API.

How to reproduce

Steps to Reproduce:

1. Create an Iceberg catalog with the following properties:
   • io-impl: org.apache.iceberg.hadoop.HadoopFileIO
   • catalog-backend: hive
   • credential-providers: s3-secret-key
   • gravitino.bypass.fs.s3a.secret.key: <secret_value>
2. Call GET /api/catalogs/{catalog_name} or list catalogs with details.

Actual Behavior:
The gravitino.bypass.fs.s3a.secret.key value is returned in plaintext:

{
  "name": "iceberg-hms-dev",
  "type": "relational",
  "provider": "lakehouse-iceberg",
  "comment": "Iceberg Lakehouse Catalog.",
  "properties": {
    "io-impl": "org.apache.iceberg.hadoop.HadoopFileIO",
    "fs.s3a.connection.timeout": "10000",
    "fs.s3a.socket.timeout": "10000",
    "gravitino.bypass.fs.s3a.endpoint": "https://s3.mycloud.com",
    "authentication.type": "simple",
    "gravitino.bypass.fs.s3a.access.key": "accesskey",
    "gravitino.bypass.fs.s3a.secret.key": "accesssecret",
    "warehouse": "s3a://tmp",
    "credential-providers": "s3-secret-key",
    "uri": "thrift://metastore.hive-metastore:9083",
    "s3-endpoint": "https://s3.mycloud.com",
    "gravitino.bypass.fs.s3a.connection.timeout": "30000",
    "gravitino.bypass.fs.s3a.socket.timeout": "10000",
    "in-use": "true",
    "catalog-backend": "hive",
    "s3-path-style-access": "true",
    "gravitino.bypass.fs.s3a.path.style.access": "true",
    "s3-region": "asia-02"
  },
  "audit": {
    "creator": "vanphuoc3012@gmail.com.vn",
    "createTime": "2026-07-18T12:32:32.210271652Z",
    "lastModifier": "vanphuoc3012@gmail.com.vn",
    "lastModifiedTime": "2026-07-20T11:31:16.223164221Z"
  }
}

Additional context

Additional Context:
We are using HadoopFileIO instead of Iceberg's native S3FileIO because our cloud S3 provider is backed by Ceph and does not support checksums. S3FileIO currently does not provide a way to disable or configure the checksum algorithm, which makes it incompatible with this provider. See the related upstream Iceberg issue: Add a property to configure the checksum algorithm in S3FileIO.

Because of this, the S3 credentials must be passed through Hadoop/S3A (gravitino.bypass.fs.s3a.*) rather than through Iceberg's native S3 properties, and the secret key is unexpectedly surfaced in catalog API responses.

[roryqi]

@diqiu50 Could u take a look at this pull request?

[diqiu50]

This is a known issue. What are your thoughts on it?
We simply pass through properties specified via *.bypass without any processing.