S3CSI-195: Update user-facing docs for secret configuration requirement

Update dynamic provisioning user documentation to reflect actual behavior:

Changes to overview.md:
- Clarify two authentication modes (secret-based vs driver-level)
- Emphasize both secrets must be configured together
- Explain CSI limitation preventing node-only secret detection

Changes to storageclass-reference-and-usage-examples.md:
- Removed misleading 'only node-publish-secret' example
- Removed 'only provisioner-secret' example
- Added 'shared secret' example showing both pointing to same Secret
- Added warning callout about single secret configuration

These updates align user-facing docs with the implementation and prevent
users from attempting unsupported configurations.

Author: anurag4DSB

docs/volume-provisioning/dynamic-provisioning/overview.md

@@ -167,12 +167,20 @@ Dynamic provisioning supports all [mount options](../mount-options.md) through t
 
 ## Authentication
 
-Dynamic provisioning requires two sets of credentials. If either or both credential types are missing from the StorageClass configuration, the CSI driver will fall back to the default driver-level credentials.
+Dynamic provisioning supports two authentication modes:
 
-1. **Provisioner Secrets**: Used by CSI controller for bucket creation and deletion
-2. **Node Secrets**: Used by nodes for mounting operations
+1. **Secret-based Authentication (Recommended)**: Configure **both** `provisioner-secret` and `node-publish-secret` in StorageClass
+   - **Provisioner Secret**: Used by CSI controller for bucket creation/deletion
+   - **Node-Publish Secret**: Used by nodes for mounting operations
+   - Both secrets can point to the same Secret or different Secrets (for least privilege)
 
-See the [Credential Management Guide](../../architecture/ring-s3-credentials-management/dynamic-provisioning-credentials-management.md) for detailed configuration.
+2. **Driver-level Authentication**: Omit both secret parameters to use driver-level credentials for all operations
+
+**Important:** Both secrets must be configured together when using secret-based authentication.
+The controller cannot detect if only `node-publish-secret` is configured (CSI specification limitation),
+so configuring only one secret will result in driver-level credentials being used.
+
+See the [Credential Management Guide](../../architecture/ring-s3-credentials-management/dynamic-provisioning-credentials-management.md) for detailed configuration and examples.
 
 ## Limitations
 

docs/volume-provisioning/dynamic-provisioning/storageclass-reference-and-usage-examples.md

@@ -50,37 +50,29 @@ mountOptions:
   - allow-other
 ```
 
-```yaml title="Only node publish secrets - Driver level secrets will be used for CreateBucket and DeleteBucket operations"
+```yaml title="Same secret for both provisioner and node operations"
 apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
-  name: s3-basic
+  name: s3-shared-secret
 provisioner: s3.csi.scality.com
 reclaimPolicy: Delete
 volumeBindingMode: Immediate
 parameters:
-  csi.storage.k8s.io/node-publish-secret-name: s3-node-secret
+  # Both secrets point to the same Secret
+  csi.storage.k8s.io/provisioner-secret-name: s3-shared-credentials
+  csi.storage.k8s.io/provisioner-secret-namespace: kube-system
+  csi.storage.k8s.io/node-publish-secret-name: s3-shared-credentials
   csi.storage.k8s.io/node-publish-secret-namespace: kube-system
 mountOptions:
   - allow-delete
   - allow-other
 ```
 
-```yaml title="Only provisioner secrets - Driver level secrets will be used for mount operations"
-apiVersion: storage.k8s.io/v1
-kind: StorageClass
-metadata:
-  name: s3-basic
-provisioner: s3.csi.scality.com
-reclaimPolicy: Delete
-volumeBindingMode: Immediate
-parameters:
-  csi.storage.k8s.io/provisioner-secret-name: s3-provisioner-secret
-  csi.storage.k8s.io/provisioner-secret-namespace: kube-system
-mountOptions:
-  - allow-delete
-  - allow-other
-```
+!!! warning "Single Secret Configuration Not Supported"
+    Configuring only `provisioner-secret` OR only `node-publish-secret` is **not recommended** and may not work as expected.
+    The controller uses `provisioner-secret` presence to determine if secret-based authentication is enabled (CSI spec limitation).
+    Always configure both secrets together, pointing to the same Secret if you don't need separate admin/user credentials.
 
 ```yaml title="No secrets - Driver level secrets will be used for CreateBucket, DeleteBucket and mount operations"
 apiVersion: storage.k8s.io/v1