doc: updated

Author: kchain-solutions

README.md

@@ -199,29 +199,6 @@ VAULT_ADDR=http://127.0.0.1:8100 VAULT_AGENT_MODE=true cargo run --package vault
 - [x] `KeyGet` - Retrieve public keys
 - [x] `Signer` - Low-level signing interface
 
-### ✅ AWS KMS Adapter
-- [x] Environment-based configuration
-- [x] Key generation with ECC_NIST_P256 (default)
-- [x] ECDSA_SHA_256 signatures
-- [x] Key existence checking
-- [x] Public key retrieval
-- [x] Scheduled key deletion
-- [x] IAM integration
-- [x] CloudTrail audit support
-
-### ✅ HashiCorp Vault Adapter
-- [x] Environment-based configuration
-- [x] Key generation with ECDSA P-256 (secp256r1)
-- [x] ECDSA signatures with Transit secrets engine
-- [x] Key existence checking
-- [x] Public key retrieval in DER format
-- [x] Key deletion with proper policies
-- [x] Docker containerization for local testing
-- [x] IOTA testnet transaction support
-- [x] Vault Agent sidecar mode for Kubernetes
-- [x] ServiceAccount-based authentication
-- [x] Automatic token rotation support
-
 ### ✅ Builder Pattern
 - [x] Auto-detection of available adapters
 - [x] Manual adapter configuration
@@ -238,11 +215,9 @@ VAULT_ADDR=http://127.0.0.1:8100 VAULT_AGENT_MODE=true cargo run --package vault
 
 The architecture supports additional adapters:
 
-- **File System Storage** - For development and testing
-- **DFNS Service** - Multi-party computation
-- **Azure Key Vault** - Microsoft cloud HSM
-- **Google Cloud KMS** - Google cloud key management
-- **Hardware Security Modules** - Direct HSM integration
+- **File System Storage** (For development and testing)
+- **DFNS Service** 
+- **Turnkey Service** 
 
 ## 🔒 Security Considerations
 
@@ -263,26 +238,10 @@ The system provides atomic 'permissions' such as `KeyRead`, `KeySign`, etc., all
 ### Explicit Boundaries Principle
 Clear interface definitions separate provider code from user code, emphasizing responsibility boundaries.
 
-## 🤝 Contributing
-
-1. Follow the hexagonal architecture principles
-2. All comments must be in English
-3. Implement comprehensive tests for new adapters
-4. Update documentation for new features
-5. Follow existing code style and conventions
-
 ## 📜 License
 
 Apache-2.0
 
-## 🏢 Enterprise Roadmap
-
-- **Multi-tenancy support** (planned)
-- **Key rotation mechanisms** (planned)  
-- **Compliance reporting** (planned)
-- **Performance monitoring** (planned)
-- **Policy engines** (planned)
-
 ---
 
 ## 📚 Additional Documentation

VAULT_INTEGRATION.md

@@ -210,27 +210,10 @@ All secret-storage-core traits are fully implemented for HashiCorp Vault:
 # Start Vault with Docker Compose
 docker-compose -f docker-compose.vault.yml up -d
 
-# Check status
-docker-compose -f docker-compose.vault.yml ps
-
-# View logs
-docker-compose -f docker-compose.vault.yml logs -f vault
-
 # Stop and clean up
 docker-compose -f docker-compose.vault.yml down
 ```
 
-## 🧪 Testing
-
-### **Unit Tests**
-```bash
-# Test Vault adapter
-cargo test --package vault-adapter
-
-# Test storage factory (includes all adapters)
-cargo test --package storage-factory
-```
-
 ### **Integration Tests**
 ```bash
 # Start Vault development server
@@ -244,22 +227,6 @@ cargo run --package storage-factory --example iota_vault_demo
 
 ## 🚀 Production Deployment
 
-### **Standard Vault Configuration**
-```hcl
-# Enable Transit secrets engine
-vault secrets enable -path=iota-transit transit
-
-# Create policy for IOTA operations
-vault policy write iota-policy - <<EOF
-path "iota-transit/keys/*" {
-  capabilities = ["create", "read", "update", "delete", "list"]
-}
-path "iota-transit/sign/*" {
-  capabilities = ["update"]
-}
-EOF
-```
-
 ### **Environment Configuration (Standard Mode)**
 ```bash
 # Production environment
@@ -272,179 +239,6 @@ export VAULT_MOUNT_PATH="iota-transit"
 
 The recommended approach for Kubernetes deployments uses the Vault Agent sidecar pattern for enhanced security.
 
-**Benefits:**
-- ✅ No long-lived secrets in pods
-- ✅ Automatic token rotation (e.g., TTL 1h)
-- ✅ ServiceAccount-based authentication
-- ✅ Reduced attack surface
-- ✅ Zero secret management in app code
-
-**Step 1: Enable Kubernetes Authentication in Vault**
-
-```bash
-# Enable Kubernetes auth method
-vault auth enable kubernetes
-
-# Configure Kubernetes authentication
-vault write auth/kubernetes/config \
-    kubernetes_host="https://kubernetes.default.svc" \
-    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
-    token_reviewer_jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token
-
-# Create role for IOTA app
-vault write auth/kubernetes/role/iota-app \
-    bound_service_account_names=iota-app \
-    bound_service_account_namespaces=iota \
-    policies=iota-policy \
-    ttl=1h
-```
-
-**Step 2: Create Vault Agent ConfigMap**
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: vault-agent-config
-  namespace: iota
-data:
-  agent.hcl: |
-    # Auto-authentication using Kubernetes ServiceAccount
-    auto_auth {
-      method "kubernetes" {
-        mount_path = "auth/kubernetes"
-        config = {
-          role = "iota-app"
-        }
-      }
-      
-      sink "file" {
-        config = {
-          path = "/vault/secrets/token"
-        }
-      }
-    }
-
-    # API proxy with automatic token injection
-    api_proxy {
-      use_auto_auth_token = true
-    }
-
-    # Local listener for app connections
-    listener "tcp" {
-      address = "127.0.0.1:8100"
-      tls_disable = true
-    }
-
-    # Vault server address
-    vault {
-      address = "https://vault.company.com:8200"
-    }
-```
-
-**Step 3: Deploy Application with Sidecar**
-
-```yaml
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: iota-app
-  namespace: iota
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: iota-app
-  namespace: iota
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      app: iota-app
-  template:
-    metadata:
-      labels:
-        app: iota-app
-    spec:
-      serviceAccountName: iota-app
-      
-      containers:
-      # Main application container
-      - name: app
-        image: iota-app:latest
-        env:
-        # Point to local Vault Agent proxy
-        - name: VAULT_ADDR
-          value: "http://127.0.0.1:8100"
-        # Enable Vault Agent mode (no token needed)
-        - name: VAULT_AGENT_MODE
-          value: "true"
-        - name: VAULT_MOUNT_PATH
-          value: "iota-transit"
-        ports:
-        - containerPort: 8080
-        resources:
-          requests:
-            cpu: 100m
-            memory: 128Mi
-          limits:
-            cpu: 500m
-            memory: 512Mi
-      
-      # Vault Agent sidecar
-      - name: vault-agent
-        image: hashicorp/vault:1.15
-        args:
-        - "agent"
-        - "-config=/vault/config/agent.hcl"
-        env:
-        - name: VAULT_ADDR
-          value: "https://vault.company.com:8200"
-        volumeMounts:
-        - name: vault-config
-          mountPath: /vault/config
-        - name: vault-secrets
-          mountPath: /vault/secrets
-        resources:
-          requests:
-            cpu: 50m
-            memory: 64Mi
-          limits:
-            cpu: 200m
-            memory: 256Mi
-      
-      volumes:
-      - name: vault-config
-        configMap:
-          name: vault-agent-config
-      - name: vault-secrets
-        emptyDir:
-          medium: Memory
-```
-
-**Step 4: Deploy and Verify**
-
-```bash
-# Apply all resources
-kubectl apply -f vault-agent-configmap.yaml
-kubectl apply -f iota-app-deployment.yaml
-
-# Check pod status
-kubectl get pods -n iota
-
-# Verify both containers are running
-kubectl describe pod -n iota <pod-name>
-
-# Check application logs
-kubectl logs -n iota <pod-name> -c app
-
-# Check Vault Agent logs
-kubectl logs -n iota <pod-name> -c vault-agent
-
-# Test the application
-kubectl port-forward -n iota <pod-name> 8080:8080
-```
-
 **Application Code (No Changes Required!):**
 
 ```rust
@@ -465,21 +259,6 @@ async fn main() -> Result<(), Box<dyn std::error::Error>> {
 }
 ```
 
-## 📊 Performance Characteristics
-
-- **Key Generation**: ~200-500ms (network dependent)
-- **Signing Operations**: ~100-300ms (network dependent)
-- **Concurrent Operations**: Supported (Vault handles concurrency)
-- **Scalability**: Enterprise-grade with Vault clustering
-
-## 🔒 Security Features
-
-- **Hardware Security**: Keys secured in Vault's encryption boundary
-- **Audit Logging**: Complete audit trail through Vault logs
-- **Access Control**: Fine-grained policies and authentication
-- **Network Security**: TLS encryption for all communications
-- **Key Isolation**: Strong isolation between different applications/tenants
-
 ## 🎉 Summary
 
 The HashiCorp Vault adapter provides a complete, enterprise-ready alternative to AWS KMS for IOTA secret storage, featuring: