Redmineの設定

🎯 概要¶

BusyBox環境などの制限された環境でもインフラヘルパーが確実に動作するよう、セキュリティポリシーへの対応と環境設定の外部化を実施する。

📋 実装内容¶

1. セキュアな互換性ヘルパーの実装

• 環境の能力を自動検出
• 段階的なフォールバック機構
• キャッシング機能
• セキュリティポリシーに準拠した実装

2. 環境設定の外部化

• すべての設定を環境変数で制御可能
• デフォルト値の適切な設定
• 設定の検証機能

3. Docker/Kubernetes対応

• セキュリティコンテキストの設定
• 読み取り専用ファイルシステム対応
• 最小権限での動作

🔧 主要な実装ファイル¶

backend/utils/secureCompatibility.js¶

class SecureCompatibilityHelper {
    // 環境能力の検出
    async detectCapabilities()
    
    // セキュアなアップタイム取得
    async getSystemUptime()
    
    // セキュアなメモリ情報取得
    async getMemoryInfo()
}

backend/config/compatibility.js¶

module.exports = {
    compatibility: {
        uptimeSources: ['proc', 'process', 'docker'],
        memorySources: ['proc', 'os', 'docker'],
        allowProcAccess: true,
        allowExecCommands: false,
        cacheEnabled: true,
        cacheTTL: 60000
    },
    security: {
        allowedPaths: ['/proc/uptime', '/proc/meminfo'],
        allowedCommands: ['uptime', 'free'],
        sandboxMode: false
    }
};

📊 期待される効果¶

1. セキュリティ向上

   • 最小権限の原則に従った動作
   • セキュリティポリシーへの適合
   • 攻撃面の削減

2. 可搬性の向上

   • 様々な環境での動作保証
   • Kubernetes、OpenShift対応
   • コンテナセキュリティベストプラクティス準拠

3. 運用の柔軟性

   • 環境変数による動的設定
   • 段階的なフォールバック
   • 詳細な能力検出とログ

🏗️ アーキテクチャ¶

┌─────────────────────────────────────┐
│         Application Layer           │
├─────────────────────────────────────┤
│    SecureCompatibilityHelper        │
├─────────────────────────────────────┤
│     Capability Detection Layer      │
├─────────────────────────────────────┤
│   Data Source Abstraction Layer     │
├─────────┬─────────┬────────────────┤
│   /proc  │   OS    │    Docker      │
│  Access  │  APIs   │     API        │
└─────────┴─────────┴────────────────┘

🔒 セキュリティ考慮事項¶

1. 最小権限の原則

   • 必要最小限のケーパビリティのみ要求
   • 読み取り専用ファイルシステムで動作可能
   • root権限不要

2. 入力検証

   • パスのホワイトリスト化
   • コマンドのホワイトリスト化
   • タイムアウト設定

3. エラーハンドリング

   • 機密情報を含まないエラーメッセージ
   • 適切なフォールバック
   • 詳細なログ（デバッグ時のみ）

🧪 テスト計画¶

1. 単体テスト

   • 各データソースのモック
   • フォールバック動作の検証
   • キャッシュ動作の検証

2. 統合テスト

   • 実環境での動作確認
   • 制限された環境でのテスト
   • パフォーマンステスト

3. セキュリティテスト

   • 権限昇格の試行
   • パストラバーサルの試行
   • リソース枯渇攻撃

📝 設定例¶

通常環境¶

NODE_ENV=production
UPTIME_SOURCES=proc,process,docker
MEMORY_SOURCES=proc,os,docker
ALLOW_PROC_ACCESS=true
ALLOW_EXEC_COMMANDS=false

制限された環境（Kubernetes）¶

NODE_ENV=production
SANDBOX_MODE=true
UPTIME_SOURCES=process
MEMORY_SOURCES=os
ALLOW_PROC_ACCESS=false
ALLOW_EXEC_COMMANDS=false

開発環境¶

NODE_ENV=development
LOG_LEVEL=debug
CACHE_ENABLED=false
ALLOW_EXEC_COMMANDS=true

🚀 デプロイメント¶

Docker Compose¶

services:
  infra-helper-api:
    environment:
      - SANDBOX_MODE=false
      - ALLOW_PROC_ACCESS=true
    security_opt:
      - no-new-privileges:true
    read_only: true
    cap_drop:
      - ALL

Kubernetes¶

securityContext:
  runAsNonRoot: true
  runAsUser: 1001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
    - ALL

🔧 実装計画¶

1. SecureCompatibilityHelperの実装（2日）
2. 設定システムの実装（1日）
3. 既存コードの移行（1日）
4. セキュリティテスト（1日）
5. ドキュメント作成（0.5日）

✅ 完了条件¶

• 制限された環境でも基本機能が動作
• すべての設定が環境変数で制御可能
• セキュリティスキャンでの脆弱性0件
• Kubernetes環境でのデプロイ成功
• 能力検出とフォールバックのテスト完了