Compare commits
5
Commits
v0.1
..
f63417b1eb
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
f63417b1eb | ||
|
|
3956928dc1 | ||
|
|
e3e54512a4 | ||
|
|
1936e54b5f | ||
|
|
3b1b04f772 |
@@ -1,6 +1,11 @@
|
||||
# Bitwarden configuration files containing secrets
|
||||
bitwarden-config.conf
|
||||
bitwarden-config.conf.dev
|
||||
*.conf
|
||||
!*.conf.sample
|
||||
|
||||
# Test files
|
||||
tests/test-bitwarden-config.conf
|
||||
|
||||
# Log files
|
||||
*.log
|
||||
@@ -9,6 +14,9 @@ bitwarden-config.conf
|
||||
# Session files
|
||||
.bw-session
|
||||
|
||||
# Generated documentation
|
||||
COMMANDS.md
|
||||
|
||||
# Backup files
|
||||
*.bak
|
||||
*.backup
|
||||
|
||||
@@ -0,0 +1,139 @@
|
||||
# TSYS Secrets Manager - Makefile
|
||||
# Provides convenient commands for testing, linting, and CI/CD
|
||||
|
||||
.PHONY: help test test-ci lint install clean check-deps vendor-test all
|
||||
|
||||
# Default target
|
||||
all: check-deps lint test
|
||||
|
||||
help: ## Show this help message
|
||||
@echo "TSYS Secrets Manager - Available Commands:"
|
||||
@echo ""
|
||||
@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf " \033[36m%-15s\033[0m %s\n", $$1, $$2}'
|
||||
|
||||
test: ## Run all tests
|
||||
@echo "Running test suite..."
|
||||
./tests/test-secrets-manager.sh run
|
||||
|
||||
test-ci: ## Run tests in CI mode (no colors, verbose output)
|
||||
@echo "Running test suite in CI mode..."
|
||||
./tests/test-secrets-manager.sh --ci run
|
||||
|
||||
test-setup: ## Setup test environment only
|
||||
./tests/test-secrets-manager.sh setup
|
||||
|
||||
test-cleanup: ## Cleanup test environment
|
||||
./tests/test-secrets-manager.sh cleanup
|
||||
|
||||
test-list: ## List available test functions
|
||||
./tests/test-secrets-manager.sh list
|
||||
|
||||
lint: ## Run shell script linting with shellcheck
|
||||
@echo "Running shellcheck..."
|
||||
@if command -v shellcheck >/dev/null 2>&1; then \
|
||||
shellcheck -x secrets-manager.sh tests/test-secrets-manager.sh bin/*.sh; \
|
||||
echo "✓ Shellcheck passed"; \
|
||||
else \
|
||||
echo "⚠ Shellcheck not found, skipping lint check"; \
|
||||
echo " Install with: apt install shellcheck"; \
|
||||
fi
|
||||
|
||||
install: ## Install dependencies and setup environment
|
||||
@echo "Installing dependencies..."
|
||||
@if command -v apt >/dev/null 2>&1; then \
|
||||
sudo apt update && sudo apt install -y shellcheck; \
|
||||
elif command -v dnf >/dev/null 2>&1; then \
|
||||
sudo dnf install -y ShellCheck; \
|
||||
elif command -v yum >/dev/null 2>&1; then \
|
||||
sudo yum install -y ShellCheck; \
|
||||
else \
|
||||
echo "⚠ Package manager not detected, please install shellcheck manually"; \
|
||||
fi
|
||||
@echo "Making scripts executable..."
|
||||
chmod +x secrets-manager.sh tests/test-secrets-manager.sh bin/*.sh
|
||||
|
||||
check-deps: ## Check for required dependencies
|
||||
@echo "Checking dependencies..."
|
||||
@echo -n "bash: "; command -v bash >/dev/null 2>&1 && echo "✓" || echo "✗ Required"
|
||||
@echo -n "shellcheck: "; command -v shellcheck >/dev/null 2>&1 && echo "✓" || echo "⚠ Optional (for linting)"
|
||||
@echo -n "git: "; command -v git >/dev/null 2>&1 && echo "✓" || echo "⚠ Optional (for version control)"
|
||||
@echo -n "make: "; command -v make >/dev/null 2>&1 && echo "✓" || echo "⚠ Optional (you're using it now)"
|
||||
|
||||
vendor-test: ## Test script as if vendored into another project
|
||||
@echo "Testing vendor integration..."
|
||||
@mkdir -p /tmp/vendor-test
|
||||
@cp secrets-manager.sh config/bitwarden-config.conf.sample /tmp/vendor-test/
|
||||
@cp tests/test-secrets-manager.sh /tmp/vendor-test/
|
||||
@cd /tmp/vendor-test && chmod +x test-secrets-manager.sh && ./test-secrets-manager.sh --ci run
|
||||
@rm -rf /tmp/vendor-test
|
||||
@echo "✓ Vendor integration test passed"
|
||||
|
||||
clean: ## Clean up temporary files and logs
|
||||
@echo "Cleaning up..."
|
||||
@rm -f /tmp/secrets-manager*.log
|
||||
@rm -f tests/test-bitwarden-config.conf
|
||||
@rm -rf /tmp/vendor-test
|
||||
@echo "✓ Cleanup complete"
|
||||
|
||||
validate-config: ## Validate sample configuration file
|
||||
@echo "Validating configuration files..."
|
||||
@if [ -f config/bitwarden-config.conf.sample ]; then \
|
||||
echo "✓ Sample config exists"; \
|
||||
grep -q "BW_SERVER_URL" config/bitwarden-config.conf.sample && echo "✓ Server URL configured" || echo "✗ Missing server URL"; \
|
||||
grep -q "BW_CLIENTID" config/bitwarden-config.conf.sample && echo "✓ Client ID configured" || echo "✗ Missing client ID"; \
|
||||
grep -q "BW_CLIENTSECRET" config/bitwarden-config.conf.sample && echo "✓ Client secret configured" || echo "✗ Missing client secret"; \
|
||||
grep -q "BW_PASSWORD" config/bitwarden-config.conf.sample && echo "✓ Password configured" || echo "✗ Missing password"; \
|
||||
else \
|
||||
echo "✗ Sample config not found"; \
|
||||
fi
|
||||
|
||||
security-check: ## Run basic security checks
|
||||
@echo "Running security checks..."
|
||||
@echo "Checking for hardcoded secrets..."
|
||||
@if grep -r -i "password\|secret\|key" --include="*.sh" --exclude="*test*" . | grep -v "BW_" | grep -v "your_.*_here" | grep -v "test_" >/dev/null; then \
|
||||
echo "⚠ Potential hardcoded secrets found:"; \
|
||||
grep -r -i "password\|secret\|key" --include="*.sh" --exclude="*test*" . | grep -v "BW_" | grep -v "your_.*_here" | grep -v "test_"; \
|
||||
else \
|
||||
echo "✓ No hardcoded secrets detected"; \
|
||||
fi
|
||||
@echo "Checking file permissions..."
|
||||
@find . -name "*.sh" -not -perm 755 -exec echo "⚠ Script not executable: {}" \; || echo "✓ Script permissions OK"
|
||||
|
||||
ci: check-deps lint test-ci security-check ## Run full CI pipeline
|
||||
@echo "✓ CI pipeline completed successfully"
|
||||
|
||||
docs: ## Generate documentation
|
||||
@echo "Generating documentation..."
|
||||
@echo "Available commands:" > COMMANDS.md
|
||||
@echo "" >> COMMANDS.md
|
||||
@./secrets-manager.sh --help >> COMMANDS.md
|
||||
@echo "" >> COMMANDS.md
|
||||
@echo "Test commands:" >> COMMANDS.md
|
||||
@echo "" >> COMMANDS.md
|
||||
@./test-secrets-manager.sh --help >> COMMANDS.md
|
||||
@echo "✓ Documentation generated in COMMANDS.md"
|
||||
|
||||
# Development helpers
|
||||
dev-setup: install ## Setup development environment
|
||||
@echo "Setting up development environment..."
|
||||
@cp config/bitwarden-config.conf.sample bitwarden-config.conf.dev
|
||||
@echo "✓ Development environment ready"
|
||||
@echo " Edit bitwarden-config.conf.dev with your development credentials"
|
||||
|
||||
dev-test: ## Run tests with development config
|
||||
@if [ -f bitwarden-config.conf.dev ]; then \
|
||||
cp bitwarden-config.conf.dev bitwarden-config.conf; \
|
||||
$(MAKE) test; \
|
||||
rm -f bitwarden-config.conf; \
|
||||
else \
|
||||
echo "⚠ No development config found. Run 'make dev-setup' first."; \
|
||||
fi
|
||||
|
||||
# Version management
|
||||
version: ## Show current version
|
||||
@./secrets-manager.sh --version
|
||||
|
||||
release-check: ## Check if ready for release
|
||||
@echo "Checking release readiness..."
|
||||
@$(MAKE) ci
|
||||
@echo "✓ All checks passed - ready for release"
|
||||
@@ -1,167 +1,5 @@
|
||||
# TSYS Secrets Manager
|
||||
# KNELSecretsManager (ARCHIVED — moved to KNEL/secrets)
|
||||
|
||||
A comprehensive bash script solution for managing secrets at TSYS using the Bitwarden CLI. This tool provides automated installation, configuration, and secure secret retrieval from your Bitwarden vault.
|
||||
This body of work moved to **[KNEL/secrets](https://git.knownelement.com/KNEL/secrets)** per the 2026-09-03 repo split ([#769](https://projects.knownelement.com/issues/769)); content was ported as `legacy-knelsecretsmanager/` (secret-scanned clean — placeholders only).
|
||||
|
||||
## Features
|
||||
|
||||
- **Automated Installation**: Automatically detects and installs Bitwarden CLI via multiple methods (snap, npm, direct download)
|
||||
- **Configuration Management**: Uses secure configuration files for server and authentication details
|
||||
- **Multiple Commands**: Support for installation, secret retrieval, listing, and testing
|
||||
- **Robust Error Handling**: Comprehensive error codes and detailed logging
|
||||
- **Security-First**: Proper session management, cleanup, and credential handling
|
||||
- **Cross-Platform**: Designed for Linux environments with multiple installation fallbacks
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. **Clone and Setup**:
|
||||
```bash
|
||||
git clone <repository-url>
|
||||
cd KNELSecretsManager
|
||||
chmod +x secrets-manager.sh
|
||||
```
|
||||
|
||||
2. **Create Configuration**:
|
||||
```bash
|
||||
cp bitwarden-config.conf.sample bitwarden-config.conf
|
||||
# Edit bitwarden-config.conf with your actual Bitwarden credentials
|
||||
```
|
||||
|
||||
3. **Install Bitwarden CLI** (if not already installed):
|
||||
```bash
|
||||
./secrets-manager.sh install
|
||||
```
|
||||
|
||||
4. **Test Your Setup**:
|
||||
```bash
|
||||
./secrets-manager.sh test
|
||||
```
|
||||
|
||||
5. **Retrieve Secrets**:
|
||||
```bash
|
||||
./secrets-manager.sh get APIKEY-pushover
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
Create a `bitwarden-config.conf` file based on the provided sample:
|
||||
|
||||
```bash
|
||||
# Bitwarden server URL
|
||||
BW_SERVER_URL="https://pwvault.turnsys.com"
|
||||
|
||||
# API credentials (from Bitwarden account settings)
|
||||
BW_CLIENTID="your_client_id_here"
|
||||
BW_CLIENTSECRET="your_client_secret_here"
|
||||
|
||||
# Master password
|
||||
BW_PASSWORD="your_master_password_here"
|
||||
```
|
||||
|
||||
**Security Note**: The actual configuration file is automatically ignored by git to prevent credential exposure.
|
||||
|
||||
## Usage
|
||||
|
||||
### Command Reference
|
||||
|
||||
```bash
|
||||
./secrets-manager.sh [OPTIONS] COMMAND [ARGS]
|
||||
```
|
||||
|
||||
#### Commands
|
||||
|
||||
- **`install`** - Install Bitwarden CLI
|
||||
- **`get <secret_name>`** - Retrieve a specific secret
|
||||
- **`list`** - List all available secrets in your vault
|
||||
- **`test`** - Test configuration and connectivity
|
||||
|
||||
#### Options
|
||||
|
||||
- **`-c, --config FILE`** - Use specific config file (default: `./bitwarden-config.conf`)
|
||||
- **`-h, --help`** - Show help message
|
||||
- **`-v, --version`** - Show version information
|
||||
|
||||
### Examples
|
||||
|
||||
```bash
|
||||
# Install Bitwarden CLI
|
||||
./secrets-manager.sh install
|
||||
|
||||
# Test your configuration
|
||||
./secrets-manager.sh test
|
||||
|
||||
# Get a specific secret
|
||||
./secrets-manager.sh get APIKEY-pushover
|
||||
|
||||
# List all available secrets
|
||||
./secrets-manager.sh list
|
||||
|
||||
# Use a custom config file
|
||||
./secrets-manager.sh --config /path/to/custom.conf get my-secret
|
||||
```
|
||||
|
||||
### Using in Scripts
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Example: Load API key into environment variable
|
||||
export PUSHOVER_API="$(./secrets-manager.sh get APIKEY-pushover)"
|
||||
|
||||
# Use the secret in your application
|
||||
curl -X POST "https://api.pushover.net/1/messages.json" \
|
||||
-d "token=$PUSHOVER_API" \
|
||||
-d "user=your_user_key" \
|
||||
-d "message=Hello from TSYS!"
|
||||
```
|
||||
|
||||
## Installation Methods
|
||||
|
||||
The script automatically tries multiple installation methods in order:
|
||||
|
||||
1. **Snap Package** (if snapd is available)
|
||||
2. **NPM Global Package** (if npm is available)
|
||||
3. **Direct Binary Download** (fallback method)
|
||||
|
||||
## Error Codes
|
||||
|
||||
| Code | Description |
|
||||
|------|-------------|
|
||||
| 10 | Configuration file not found |
|
||||
| 20 | Bitwarden CLI not installed |
|
||||
| 30 | Bitwarden CLI installation failed |
|
||||
| 40 | Server configuration failed |
|
||||
| 50 | Session/unlock failed |
|
||||
| 60 | Secret not found |
|
||||
| 70 | Login failed |
|
||||
|
||||
## Logging
|
||||
|
||||
All operations are logged to `/tmp/secrets-manager.sh.log` for debugging and audit purposes.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
- Configuration files containing credentials are automatically gitignored
|
||||
- Session tokens are properly cleaned up on script exit
|
||||
- Master passwords are handled securely without shell history exposure
|
||||
- All sensitive operations include proper error handling
|
||||
|
||||
## Legacy Scripts
|
||||
|
||||
This repository also contains previous implementations:
|
||||
|
||||
- **`poc.sh`** - Original proof of concept
|
||||
- **`prod.sh`** - ChatGPT-assisted production attempt
|
||||
|
||||
The new `secrets-manager.sh` combines the best features of both while adding robust error handling, installation management, and improved security.
|
||||
|
||||
## Contributing
|
||||
|
||||
When contributing to this project:
|
||||
|
||||
1. Test all changes thoroughly
|
||||
2. Update documentation as needed
|
||||
3. Follow existing code style and conventions
|
||||
4. Ensure security best practices are maintained
|
||||
|
||||
## License
|
||||
|
||||
See [LICENSE](LICENSE) file for details.
|
||||
This repo is historical. New secrets-management work happens in KNEL/secrets (#770).
|
||||
|
||||
Executable
+75
@@ -0,0 +1,75 @@
|
||||
#!/usr/bin/env bash
|
||||
# bw-cli.sh — Bitwarden CLI host wrapper (container-based, native Rust binary).
|
||||
#
|
||||
# Provides transparent `bw` access on hosts where the CLI is not installed
|
||||
# natively. Runs the pre-compiled Rust bw binary inside a minimal Docker
|
||||
# container (debian-slim + ca-certificates, NO Node.js).
|
||||
#
|
||||
# All tool execution happens inside the container. Nothing runs on the host
|
||||
# except this wrapper, which only invokes docker.
|
||||
#
|
||||
# Usage:
|
||||
# bw-cli.sh status Check vault status
|
||||
# bw-cli.sh list items List vault items
|
||||
# bw-cli.sh list collections List collections
|
||||
# bw-cli.sh get password "Item" Retrieve a password
|
||||
# bw-cli.sh get totp "Item" Retrieve a TOTP code
|
||||
# bw-cli.sh get item "Item" Full item JSON
|
||||
# bw-cli.sh generate -ulns Generate a password
|
||||
#
|
||||
# Install to ~/.local/bin/bw via:
|
||||
# scripts/bw-install.sh
|
||||
#
|
||||
# Environment overrides:
|
||||
# BW_ENV_FILE Path to credentials (default: ~/.config/bw/env)
|
||||
# BW_IMAGE Docker image (default: reachableceo-bw-native:2026.7.0)
|
||||
# BW_VOLUME Docker volume for persisted login state
|
||||
# (default: tsys-bw-cli-state)
|
||||
# BW_LIB_DIR Directory containing entrypoint.sh (default: ~/.local/share/bw)
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
BW_ENV_FILE="${BW_ENV_FILE:-$HOME/.config/bw/env}"
|
||||
BW_IMAGE="${BW_IMAGE:-reachableceo-bw-native:2026.7.0}"
|
||||
BW_VOLUME="${BW_VOLUME:-tsys-bw-cli-state}"
|
||||
BW_LIB_DIR="${BW_LIB_DIR:-$HOME/.local/share/bw}"
|
||||
|
||||
# --- Validate prerequisites ---
|
||||
if [ ! -f "$BW_ENV_FILE" ]; then
|
||||
echo "bw: credential file not found: $BW_ENV_FILE" >&2
|
||||
echo " expected BW_CLIENTID, BW_CLIENTSECRET, BW_PASSWORD, BW_SERVER" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if ! docker image inspect "$BW_IMAGE" >/dev/null 2>&1; then
|
||||
echo "bw: Docker image not found: $BW_IMAGE" >&2
|
||||
echo " build it: scripts/bw-install.sh" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if [ ! -f "$BW_LIB_DIR/entrypoint.sh" ]; then
|
||||
echo "bw: entrypoint script missing: $BW_LIB_DIR/entrypoint.sh" >&2
|
||||
echo " install via: scripts/bw-install.sh" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# --- Load credentials (values are single-quoted in env file) ---
|
||||
set -a
|
||||
# shellcheck source=/dev/null
|
||||
. "$BW_ENV_FILE"
|
||||
set +a
|
||||
|
||||
# --- Create persistent volume for BW CLI login state ---
|
||||
docker volume create "$BW_VOLUME" >/dev/null 2>&1 || true
|
||||
|
||||
# --- Run bw inside the container ---
|
||||
docker run --rm -i \
|
||||
-e BW_CLIENTID \
|
||||
-e BW_CLIENTSECRET \
|
||||
-e BW_PASSWORD \
|
||||
-e BW_SERVER \
|
||||
-v "$BW_VOLUME:/root/.config/Bitwarden CLI" \
|
||||
-v "$BW_LIB_DIR/entrypoint.sh:/opt/bw/entrypoint.sh:ro" \
|
||||
--entrypoint sh \
|
||||
"$BW_IMAGE" \
|
||||
/opt/bw/entrypoint.sh "$@"
|
||||
Executable
+44
@@ -0,0 +1,44 @@
|
||||
#!/bin/sh
|
||||
# bw-entrypoint.sh — Bitwarden auth lifecycle, runs inside the container.
|
||||
#
|
||||
# Mounted at /opt/bw/entrypoint.sh by the host-side wrapper (bw-cli.sh).
|
||||
# Handles: server config, API-key login, vault unlock, sync.
|
||||
# Then execs the real bw command with BW_SESSION set.
|
||||
#
|
||||
# API key authentication does NOT require TOTP. The API key itself is
|
||||
# obtained from an authenticated web vault session, so 2FA is already
|
||||
# satisfied at key-generation time.
|
||||
#
|
||||
# This script intentionally uses /bin/sh (not bash) for minimal container
|
||||
# compatibility. shellcheck directive below silences the "not bash" note.
|
||||
# shellcheck shell=sh
|
||||
|
||||
set -e
|
||||
|
||||
BW_SERVER="${BW_SERVER:-https://pwvault.turnsys.com}"
|
||||
|
||||
# Suppress BW CLI data-dir creation noise and telemetry.
|
||||
export BW_NO_SENTRY=true
|
||||
|
||||
# --- Step 1: Configure server (fails harmlessly if already logged in) ---
|
||||
bw config server "$BW_SERVER" >/dev/null 2>&1 || true
|
||||
|
||||
# --- Step 2: Login via API key (silently skips if already authenticated) ---
|
||||
bw login --apikey >/dev/null 2>&1 || true
|
||||
|
||||
# --- Step 3: Unlock the vault ---
|
||||
printf '%s' "$BW_PASSWORD" > /tmp/.bwpw
|
||||
SESS=$(bw unlock --passwordfile /tmp/.bwpw --raw 2>/dev/null)
|
||||
rm -f /tmp/.bwpw
|
||||
if [ -z "$SESS" ]; then
|
||||
echo "bw: unlock failed. Check BW_PASSWORD in ~/.config/bw/env" >&2
|
||||
echo " Values must be single-quoted; \$ chars get mangled if unquoted." >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# --- Step 4: Sync ---
|
||||
bw sync --session "$SESS" >/dev/null 2>&1 || true
|
||||
|
||||
# --- Step 5: Execute the requested command ---
|
||||
export BW_SESSION="$SESS"
|
||||
exec bw "$@"
|
||||
Executable
+125
@@ -0,0 +1,125 @@
|
||||
#!/usr/bin/env bash
|
||||
# bw-install.sh — Install the container-based Bitwarden CLI wrapper.
|
||||
#
|
||||
# Downloads the native Rust bw binary, builds the Docker image, and installs
|
||||
# the host-side wrapper plus container entrypoint to the user's local paths.
|
||||
# No Node.js is involved at any layer.
|
||||
#
|
||||
# Usage:
|
||||
# bw-install.sh Download, build, and install everything
|
||||
# bw-install.sh --check Verify installation status without changes
|
||||
#
|
||||
# Prerequisites:
|
||||
# - docker on PATH
|
||||
# - BW env file at ~/.config/bw/env (see prereq-check.sh in TSYSGroupAIOS)
|
||||
#
|
||||
# After install, ~/.local/bin/bw provides transparent CLI access. Add
|
||||
# ~/.local/bin to PATH if not already (most distros do this via ~/.profile).
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
REPO_ROOT="$(cd "$HERE/.." && pwd)"
|
||||
|
||||
BW_VERSION="2026.7.0"
|
||||
BW_IMAGE="reachableceo-bw-native:${BW_VERSION}"
|
||||
BW_BINARY_URL="https://github.com/bitwarden/clients/releases/download/cli-v${BW_VERSION}/bw-linux-${BW_VERSION}.zip"
|
||||
|
||||
INSTALL_BIN="${HOME}/.local/bin"
|
||||
INSTALL_LIB="${HOME}/.local/share/bw"
|
||||
BUILD_DIR=""
|
||||
|
||||
# --- Helpers ---
|
||||
log_info() { printf '\033[0;34m›\033[0m %s\n' "$*"; }
|
||||
log_ok() { printf '\033[0;32m✓\033[0m %s\n' "$*"; }
|
||||
log_warn() { printf '\033[1;33m⚠\033[0m %s\n' "$*" >&2; }
|
||||
log_error() { printf '\033[0;31m✗\033[0m %s\n' "$*" >&2; }
|
||||
log_step() { printf '\n\033[1m== %s ==\033[0m\n' "$*"; }
|
||||
die() { log_error "$*"; exit 1; }
|
||||
|
||||
# --- Cleanup on exit ---
|
||||
cleanup() {
|
||||
[ -n "$BUILD_DIR" ] && rm -rf "$BUILD_DIR"
|
||||
}
|
||||
trap cleanup EXIT
|
||||
|
||||
# --- Check mode ---
|
||||
if [ "${1:-}" = "--check" ]; then
|
||||
log_step "BW CLI installation check"
|
||||
if command -v docker >/dev/null 2>&1; then
|
||||
log_ok "docker on PATH"
|
||||
else
|
||||
log_error "docker not on PATH"
|
||||
fi
|
||||
if docker image inspect "$BW_IMAGE" >/dev/null 2>&1; then
|
||||
log_ok "Docker image ${BW_IMAGE} exists"
|
||||
else
|
||||
log_error "Docker image ${BW_IMAGE} missing"
|
||||
fi
|
||||
if [ -x "${INSTALL_BIN}/bw" ]; then
|
||||
log_ok "Host wrapper at ${INSTALL_BIN}/bw"
|
||||
else
|
||||
log_error "Host wrapper at ${INSTALL_BIN}/bw missing"
|
||||
fi
|
||||
if [ -f "${INSTALL_LIB}/entrypoint.sh" ]; then
|
||||
log_ok "Entrypoint at ${INSTALL_LIB}/entrypoint.sh"
|
||||
else
|
||||
log_error "Entrypoint at ${INSTALL_LIB}/entrypoint.sh missing"
|
||||
fi
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# --- Prerequisites ---
|
||||
command -v docker >/dev/null 2>&1 || die "docker not found on PATH"
|
||||
|
||||
log_step "Installing container-based Bitwarden CLI (native Rust, no Node.js)"
|
||||
|
||||
# --- Step 1: Download and extract the native binary ---
|
||||
BUILD_DIR=$(mktemp -d)
|
||||
log_info "Downloading bw ${BW_VERSION} native binary..."
|
||||
|
||||
docker run --rm -v "${BUILD_DIR}:/build" alpine:3.20 \
|
||||
sh -c "apk add --no-cache unzip >/dev/null 2>&1 && \
|
||||
wget -q -O /build/bw.zip '${BW_BINARY_URL}' && \
|
||||
unzip -o /build/bw.zip -d /build/ && \
|
||||
rm /build/bw.zip && \
|
||||
chmod +x /build/bw"
|
||||
|
||||
[ -f "${BUILD_DIR}/bw" ] || die "download failed: bw binary not found"
|
||||
log_ok "Downloaded native binary"
|
||||
|
||||
# --- Step 2: Build the Docker image ---
|
||||
log_info "Building Docker image ${BW_IMAGE}..."
|
||||
|
||||
DOCKERFILE_DIR="${REPO_ROOT}/docker/bw-native"
|
||||
if [ ! -f "${DOCKERFILE_DIR}/Dockerfile" ]; then
|
||||
die "Dockerfile not found: ${DOCKERFILE_DIR}/Dockerfile"
|
||||
fi
|
||||
|
||||
cp "${BUILD_DIR}/bw" "${DOCKERFILE_DIR}/bw"
|
||||
docker build -t "$BW_IMAGE" "$DOCKERFILE_DIR"
|
||||
rm -f "${DOCKERFILE_DIR}/bw"
|
||||
log_ok "Built image ${BW_IMAGE}"
|
||||
|
||||
# --- Step 3: Install host-side wrapper and entrypoint ---
|
||||
mkdir -p "$INSTALL_BIN" "$INSTALL_LIB"
|
||||
|
||||
cp "${HERE}/bw-cli.sh" "${INSTALL_BIN}/bw"
|
||||
chmod 755 "${INSTALL_BIN}/bw"
|
||||
log_ok "Installed wrapper to ${INSTALL_BIN}/bw"
|
||||
|
||||
cp "${HERE}/bw-entrypoint.sh" "${INSTALL_LIB}/entrypoint.sh"
|
||||
chmod 755 "${INSTALL_LIB}/entrypoint.sh"
|
||||
log_ok "Installed entrypoint to ${INSTALL_LIB}/entrypoint.sh"
|
||||
|
||||
# --- Step 4: Verify ---
|
||||
log_info "Verifying installation..."
|
||||
if "${INSTALL_BIN}/bw" --version >/dev/null 2>&1; then
|
||||
log_ok "bw CLI is operational"
|
||||
else
|
||||
log_warn "bw wrapper installed but verification call failed"
|
||||
log_warn "check ~/.config/bw/env credentials and try: bw status"
|
||||
fi
|
||||
|
||||
log_step "Installation complete"
|
||||
log_info "Usage: bw status | bw list items | bw get password \"Item Name\""
|
||||
@@ -0,0 +1,23 @@
|
||||
# Dockerfile — Native Bitwarden CLI (Rust binary, no Node.js)
|
||||
#
|
||||
# Builds a minimal container image around the pre-compiled native bw CLI
|
||||
# binary from the official Bitwarden GitHub releases. The binary is a
|
||||
# Rust executable with glibc dependencies. No Node.js runtime is
|
||||
# included or required.
|
||||
#
|
||||
# Build prerequisites:
|
||||
# 1. Download the native binary:
|
||||
# https://github.com/bitwarden/clients/releases/download/cli-v2026.7.0/bw-linux-2026.7.0.zip
|
||||
# 2. Unzip and place the `bw` executable next to this Dockerfile.
|
||||
# 3. Build: docker build -t reachableceo-bw-native:2026.7.0 .
|
||||
#
|
||||
# Or use the installer: scripts/bw-install.sh
|
||||
|
||||
FROM debian:bookworm-slim
|
||||
|
||||
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/*
|
||||
|
||||
COPY bw /usr/local/bin/bw
|
||||
RUN chmod +x /usr/local/bin/bw
|
||||
|
||||
ENTRYPOINT ["bw"]
|
||||
@@ -0,0 +1,77 @@
|
||||
# ADR-002: Container-Based Bitwarden CLI (No Host Node.js)
|
||||
|
||||
## Status
|
||||
|
||||
Accepted (supersedes ADR-001 for BW CLI purposes)
|
||||
|
||||
## Context
|
||||
|
||||
ADR-001 selected a hybrid Node.js version-management strategy because the
|
||||
Bitwarden CLI (`bw`) is distributed via npm and therefore requires a Node.js
|
||||
runtime on every consuming host. For TSYS hosts operating under CMMC L3 /
|
||||
ITAR / STIG alignment, any host-side language runtime is an attack surface
|
||||
and a compliance finding. The KNEL/TSYS baseline ("Docker for everything")
|
||||
also forbids host language toolchains.
|
||||
|
||||
Bitwarden additionally publishes the CLI as a pre-compiled single binary.
|
||||
Distributing that binary inside a minimal pinned container gives every host
|
||||
transparent `bw` access with zero host-side runtimes.
|
||||
|
||||
## Decision
|
||||
|
||||
**Run the official pre-compiled bw binary inside a pinned Docker container,
|
||||
exposed to users as a transparent `bw` wrapper at `~/.local/bin/bw`.**
|
||||
|
||||
Components (all in this repo):
|
||||
|
||||
| File | Role |
|
||||
|---|---|
|
||||
| `docker/bw-native/Dockerfile` | `debian:12-slim` + ca-certificates + bw binary, pinned `2026.7.0` |
|
||||
| `bin/bw-entrypoint.sh` | In-container auth lifecycle: config server, API-key login, unlock, sync, exec |
|
||||
| `bin/bw-cli.sh` | Host wrapper: docker run with volume-persisted session, tsys- container prefix |
|
||||
| `bin/bw-install.sh` | One-command installer for the wrapper + image |
|
||||
|
||||
Credentials live only in `~/.config/bw/env` (single-quoted values, mode 600)
|
||||
per the org-wide "no secrets on disk except BW access info" rule. The
|
||||
Vaultwarden API key is used for login (no TOTP interaction needed); the
|
||||
master password unlocks the vault; `bw sync` runs after every login so
|
||||
multi-client vault state stays coherent.
|
||||
|
||||
## Known Caveat
|
||||
|
||||
The Bitwarden "native" Linux binary is actually a Node.js SEA (Single
|
||||
Executable Application): it embeds a Node.js runtime and can print Node
|
||||
errors on crash. Node.js is **absent from every host**, which satisfies the
|
||||
host-hygiene goal, but the "zero Node.js anywhere" stretch goal is not met.
|
||||
Alternatives (Rust vaultwarden clients such as `rbw`) were considered and
|
||||
rejected for now due to Vaultwarden API compatibility gaps. Revisit if a
|
||||
mature Rust client emerges; the wrapper isolates users from this swap.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- Zero language runtimes on hosts (CMMC/ITAR/STIG-friendly host hygiene)
|
||||
- Identical bw behavior across all TSYS hosts; version pinned in one Dockerfile
|
||||
- Session persistence via named Docker volume; no state divergence when
|
||||
wrapper is used consistently
|
||||
- Vendoring into shell frameworks is one installer invocation
|
||||
|
||||
### Negative
|
||||
|
||||
- Requires Docker on every consuming host (accepted: it is an org baseline)
|
||||
- SEA caveat above (Node embedded inside the container image)
|
||||
|
||||
## Verification
|
||||
|
||||
Deployed and verified on the TSGCOO orchestration host against
|
||||
`https://pwvault.turnsys.com` (account `coo@turnsys.com`): status, list,
|
||||
generate, get password/totp/item, create/edit items. Shellcheck clean at
|
||||
zero warnings including info-level. In production use since 2026-08-13.
|
||||
|
||||
---
|
||||
|
||||
**Decision Date:** 2026-08-14
|
||||
**Decision Makers:** VP TechOps (proposed), TSGCOO (implemented)
|
||||
**Related:** ADR-001 (superseded for BW CLI purposes; MISE guidance remains
|
||||
valid for projects that genuinely require host Node.js)
|
||||
@@ -0,0 +1,212 @@
|
||||
# ADR-001: Node.js Version Management Strategy
|
||||
|
||||
## Status
|
||||
Proposed
|
||||
|
||||
## Context
|
||||
|
||||
The TSYS Secrets Manager project needs to make an architectural decision regarding Node.js version management across development, staging, and production environments. This decision impacts:
|
||||
|
||||
- Development workflow and environment consistency
|
||||
- Production stability and security posture
|
||||
- Operational complexity and maintenance overhead
|
||||
- Compliance with enterprise security policies
|
||||
- Integration with existing shell scripting frameworks
|
||||
|
||||
As this project will be git vendor included into shell scripting frameworks, the Node.js management approach must be portable and not introduce complex dependencies on the consuming systems.
|
||||
|
||||
## Decision Drivers
|
||||
|
||||
1. **Security and Compliance**: Enterprise security requirements mandate automated security updates and clear audit trails
|
||||
2. **Operational Simplicity**: Minimize operational overhead and complexity in production environments
|
||||
3. **Development Efficiency**: Enable developers to work with appropriate Node.js versions for different projects
|
||||
4. **Vendor Integration**: Support clean integration when vendored into other shell scripting frameworks
|
||||
5. **Stability**: Ensure production deployments are stable and predictable
|
||||
6. **Version Flexibility**: Ability to test and deploy with specific Node.js versions when needed
|
||||
|
||||
## Options Considered
|
||||
|
||||
### Option 1: MISE (Modern Infrastructure Software Engineering)
|
||||
**Description**: Use MISE for polyglot runtime version management across all environments.
|
||||
|
||||
**Pros**:
|
||||
- Zero-overhead performance (no shims, direct binary execution)
|
||||
- Multi-version support with automatic project-based switching
|
||||
- Modern Rust-based implementation with enhanced security
|
||||
- Excellent developer experience with unified tooling
|
||||
- Support for `.nvmrc` and other standard version files
|
||||
- Task runner capabilities
|
||||
|
||||
**Cons**:
|
||||
- Additional operational complexity in production
|
||||
- Custom security update processes required
|
||||
- Not managed by distribution security teams
|
||||
- Requires team training and adoption
|
||||
- May complicate vendor integration scenarios
|
||||
|
||||
### Option 2: System Package Manager (Debian apt)
|
||||
**Description**: Use distribution-provided Node.js packages for all environments.
|
||||
|
||||
**Pros**:
|
||||
- Managed by Debian security team with automatic updates
|
||||
- Battle-tested in enterprise environments
|
||||
- Integration with existing configuration management
|
||||
- Clear audit trails and compliance support
|
||||
- Minimal operational overhead
|
||||
- Standard enterprise security practices
|
||||
|
||||
**Cons**:
|
||||
- Often outdated versions (significant lag behind releases)
|
||||
- Limited to single system-wide version
|
||||
- Cannot easily test multiple Node.js versions
|
||||
- May not support latest language features
|
||||
- Difficulty matching exact versions across environments
|
||||
|
||||
### Option 3: Containerized Deployment with Official Images
|
||||
**Description**: Use official Node.js Docker images with pinned versions.
|
||||
|
||||
**Pros**:
|
||||
- Reproducible deployments with exact version control
|
||||
- Security scanning and automated vulnerability management
|
||||
- Isolation from host system dependencies
|
||||
- Industry standard approach for modern deployments
|
||||
- Easy version management through Dockerfile
|
||||
|
||||
**Cons**:
|
||||
- Requires container orchestration infrastructure
|
||||
- Additional complexity for simple script deployments
|
||||
- May be overkill for shell script frameworks
|
||||
- Learning curve for container-naive environments
|
||||
|
||||
### Option 4: Hybrid Approach
|
||||
**Description**: Use different tools for different environments and use cases.
|
||||
|
||||
**Pros**:
|
||||
- Optimized approach for each environment's specific needs
|
||||
- Flexibility to choose best tool for each scenario
|
||||
- Can evolve strategy as requirements change
|
||||
|
||||
**Cons**:
|
||||
- Increased complexity managing multiple approaches
|
||||
- Potential for environment drift and inconsistencies
|
||||
- More documentation and training required
|
||||
|
||||
## Decision
|
||||
|
||||
**Selected: Option 4 - Hybrid Approach with System Packages as Primary**
|
||||
|
||||
### Primary Strategy:
|
||||
- **Production Environments**: Use Debian system packages (apt) for Node.js installation
|
||||
- **Development Environments**: Use MISE for flexibility and multi-version testing
|
||||
- **Vendor Integration**: Document both approaches, default to system packages
|
||||
|
||||
### Rationale:
|
||||
|
||||
1. **Security-First Production**: System packages provide the security posture required for enterprise production environments with automated security updates and established audit trails.
|
||||
|
||||
2. **Development Flexibility**: MISE enables developers to test across multiple Node.js versions and maintain development-production parity when needed.
|
||||
|
||||
3. **Vendor-Friendly**: When this project is vendored into shell scripting frameworks, defaulting to system packages minimizes external dependencies and complexity for consuming systems.
|
||||
|
||||
4. **Gradual Adoption**: Teams can start with system packages and adopt MISE for development as needed, without disrupting production systems.
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
### For Production Deployments:
|
||||
```bash
|
||||
# Install Node.js via system package manager
|
||||
sudo apt update
|
||||
sudo apt install nodejs npm
|
||||
|
||||
# Verify installation
|
||||
node --version
|
||||
npm --version
|
||||
```
|
||||
|
||||
### For Development Environments:
|
||||
```bash
|
||||
# Install MISE
|
||||
curl https://mise.run | sh
|
||||
|
||||
# Configure for project
|
||||
mise use node@18.17.0
|
||||
mise use node@20.9.0 # For testing newer versions
|
||||
|
||||
# Project-specific configuration
|
||||
echo "node 18.17.0" > .tool-versions
|
||||
```
|
||||
|
||||
### For Vendor Integration:
|
||||
- Default installation scripts should use system packages
|
||||
- Provide optional MISE support for advanced users
|
||||
- Document both approaches clearly
|
||||
- Include version compatibility matrix
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive:
|
||||
- Production systems maintain enterprise security standards
|
||||
- Development teams gain version management flexibility
|
||||
- Reduced vendor integration complexity
|
||||
- Clear separation of concerns between environments
|
||||
- Future migration paths remain open
|
||||
|
||||
### Negative:
|
||||
- Increased documentation requirements
|
||||
- Potential for environment drift if not managed properly
|
||||
- Team training required for both approaches
|
||||
- Slightly more complex CI/CD pipelines
|
||||
|
||||
### Neutral:
|
||||
- Need to maintain compatibility with both package management approaches
|
||||
- Version testing required across both installation methods
|
||||
|
||||
## Compliance and Security Considerations
|
||||
|
||||
### System Package Approach:
|
||||
- Automatic security updates via `unattended-upgrades`
|
||||
- Integration with enterprise vulnerability scanners
|
||||
- Standard audit procedures apply
|
||||
- Compliance with distribution security policies
|
||||
|
||||
### MISE Approach (Development Only):
|
||||
- Manual security update processes
|
||||
- Custom vulnerability monitoring required
|
||||
- Developer responsibility for version management
|
||||
- Clear policies needed for version selection
|
||||
|
||||
## Monitoring and Metrics
|
||||
|
||||
### Track:
|
||||
- Node.js version distribution across environments
|
||||
- Security update lag time between environments
|
||||
- Developer adoption of MISE in development
|
||||
- Issues related to version mismatches
|
||||
|
||||
### Success Criteria:
|
||||
- Zero production security incidents related to Node.js versions
|
||||
- <1 week lag time for critical security updates in production
|
||||
- >90% developer satisfaction with version management workflow
|
||||
- Successful vendor integrations with minimal friction
|
||||
|
||||
## Review Schedule
|
||||
|
||||
This ADR should be reviewed:
|
||||
- Quarterly for the first year
|
||||
- Annually thereafter
|
||||
- When major Node.js LTS versions are released
|
||||
- After significant security incidents
|
||||
- When vendor integration patterns change
|
||||
|
||||
## References
|
||||
|
||||
- [MISE Documentation](https://mise.jdx.dev/)
|
||||
- [Node.js Release Schedule](https://nodejs.org/en/about/releases/)
|
||||
- [Debian Node.js Packages](https://packages.debian.org/search?keywords=nodejs)
|
||||
- [Enterprise Node.js Security Best Practices](https://nodejs.org/en/docs/guides/security/)
|
||||
|
||||
---
|
||||
|
||||
**Decision Date**: 2025-07-16
|
||||
**Decision Makers**: Architecture Team, Security Team, DevOps Team
|
||||
**Next Review**: 2025-10-16
|
||||
@@ -44,14 +44,6 @@ install_bitwarden_cli() {
|
||||
|
||||
info "Installing Bitwarden CLI..."
|
||||
|
||||
if command -v snap &>/dev/null; then
|
||||
info "Installing via snap..."
|
||||
if sudo snap install bw; then
|
||||
info "Bitwarden CLI installed successfully via snap"
|
||||
return 0
|
||||
fi
|
||||
fi
|
||||
|
||||
if command -v npm &>/dev/null; then
|
||||
info "Installing via npm..."
|
||||
if sudo npm install -g @bitwarden/cli; then
|
||||
|
||||
@@ -0,0 +1,495 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
# Test Suite for TSYS Secrets Manager
|
||||
# Designed to work standalone and when vendored into shell scripting frameworks
|
||||
|
||||
set -o errexit
|
||||
set -o nounset
|
||||
set -o pipefail
|
||||
IFS=$'\n\t'
|
||||
|
||||
# Determine script directory and main script location
|
||||
readonly TEST_SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
|
||||
# Check if we're in the organized structure or vendored
|
||||
if [[ -f "${TEST_SCRIPT_DIR}/../secrets-manager.sh" ]]; then
|
||||
# Organized structure: tests/test-secrets-manager.sh
|
||||
readonly SCRIPT_DIR="$(cd "${TEST_SCRIPT_DIR}/.." && pwd)"
|
||||
readonly SECRETS_MANAGER="${SCRIPT_DIR}/secrets-manager.sh"
|
||||
readonly TEST_CONFIG="${SCRIPT_DIR}/tests/test-bitwarden-config.conf"
|
||||
else
|
||||
# Vendored structure: all files in same directory
|
||||
readonly SCRIPT_DIR="${TEST_SCRIPT_DIR}"
|
||||
readonly SECRETS_MANAGER="${SCRIPT_DIR}/secrets-manager.sh"
|
||||
readonly TEST_CONFIG="${SCRIPT_DIR}/test-bitwarden-config.conf"
|
||||
fi
|
||||
readonly TEST_LOG="/tmp/secrets-manager-test.log"
|
||||
|
||||
# Test framework variables
|
||||
TESTS_RUN=0
|
||||
TESTS_PASSED=0
|
||||
TESTS_FAILED=0
|
||||
TEST_FAILURES=()
|
||||
|
||||
# Colors for output (disabled in CI environments)
|
||||
if [[ "${CI:-false}" == "true" ]] || [[ ! -t 1 ]]; then
|
||||
RED=""
|
||||
GREEN=""
|
||||
YELLOW=""
|
||||
BLUE=""
|
||||
RESET=""
|
||||
else
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
YELLOW='\033[1;33m'
|
||||
BLUE='\033[0;34m'
|
||||
RESET='\033[0m'
|
||||
fi
|
||||
|
||||
# Logging functions
|
||||
log_info() { echo -e "${BLUE}[INFO]${RESET} $*"; }
|
||||
log_success() { echo -e "${GREEN}[PASS]${RESET} $*"; }
|
||||
log_error() { echo -e "${RED}[FAIL]${RESET} $*"; }
|
||||
log_warn() { echo -e "${YELLOW}[WARN]${RESET} $*"; }
|
||||
|
||||
# Test framework functions
|
||||
setup_test_environment() {
|
||||
log_info "Setting up test environment..."
|
||||
|
||||
# Ensure secrets-manager.sh exists and is executable
|
||||
if [[ ! -f "$SECRETS_MANAGER" ]]; then
|
||||
log_error "secrets-manager.sh not found at $SECRETS_MANAGER"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if [[ ! -x "$SECRETS_MANAGER" ]]; then
|
||||
chmod +x "$SECRETS_MANAGER"
|
||||
fi
|
||||
|
||||
# Create test config file
|
||||
create_test_config
|
||||
|
||||
# Clear test log
|
||||
> "$TEST_LOG"
|
||||
|
||||
log_info "Test environment ready"
|
||||
}
|
||||
|
||||
create_test_config() {
|
||||
cat > "$TEST_CONFIG" <<EOF
|
||||
# Test configuration for secrets manager
|
||||
BW_SERVER_URL="https://test.bitwarden.com"
|
||||
BW_CLIENTID="test_client_id"
|
||||
BW_CLIENTSECRET="test_client_secret"
|
||||
BW_PASSWORD="test_password"
|
||||
EOF
|
||||
}
|
||||
|
||||
cleanup_test_environment() {
|
||||
log_info "Cleaning up test environment..."
|
||||
|
||||
# Remove test config
|
||||
[[ -f "$TEST_CONFIG" ]] && rm -f "$TEST_CONFIG"
|
||||
|
||||
# Remove test log
|
||||
[[ -f "$TEST_LOG" ]] && rm -f "$TEST_LOG"
|
||||
|
||||
# Clear any Bitwarden session
|
||||
unset BW_SESSION 2>/dev/null || true
|
||||
|
||||
log_info "Cleanup complete"
|
||||
}
|
||||
|
||||
run_test() {
|
||||
local test_name="$1"
|
||||
local test_function="$2"
|
||||
|
||||
((TESTS_RUN++))
|
||||
log_info "Running test: $test_name"
|
||||
|
||||
if $test_function; then
|
||||
((TESTS_PASSED++))
|
||||
log_success "$test_name"
|
||||
else
|
||||
((TESTS_FAILED++))
|
||||
TEST_FAILURES+=("$test_name")
|
||||
log_error "$test_name"
|
||||
fi
|
||||
}
|
||||
|
||||
assert_equals() {
|
||||
local expected="$1"
|
||||
local actual="$2"
|
||||
local message="${3:-}"
|
||||
|
||||
if [[ "$expected" == "$actual" ]]; then
|
||||
return 0
|
||||
else
|
||||
[[ -n "$message" ]] && log_error "$message"
|
||||
log_error "Expected: '$expected', Got: '$actual'"
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
assert_contains() {
|
||||
local haystack="$1"
|
||||
local needle="$2"
|
||||
local message="${3:-}"
|
||||
|
||||
if [[ "$haystack" == *"$needle"* ]]; then
|
||||
return 0
|
||||
else
|
||||
[[ -n "$message" ]] && log_error "$message"
|
||||
log_error "Expected '$haystack' to contain '$needle'"
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
assert_file_exists() {
|
||||
local file_path="$1"
|
||||
local message="${2:-}"
|
||||
|
||||
if [[ -f "$file_path" ]]; then
|
||||
return 0
|
||||
else
|
||||
[[ -n "$message" ]] && log_error "$message"
|
||||
log_error "File does not exist: $file_path"
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
assert_command_success() {
|
||||
local command="$1"
|
||||
local message="${2:-}"
|
||||
|
||||
if eval "$command" >/dev/null 2>&1; then
|
||||
return 0
|
||||
else
|
||||
[[ -n "$message" ]] && log_error "$message"
|
||||
log_error "Command failed: $command"
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
assert_command_failure() {
|
||||
local command="$1"
|
||||
local message="${2:-}"
|
||||
|
||||
if ! eval "$command" >/dev/null 2>&1; then
|
||||
return 0
|
||||
else
|
||||
[[ -n "$message" ]] && log_error "$message"
|
||||
log_error "Command unexpectedly succeeded: $command"
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
# Test cases
|
||||
test_script_exists_and_executable() {
|
||||
assert_file_exists "$SECRETS_MANAGER" "secrets-manager.sh should exist" &&
|
||||
assert_command_success "[[ -x '$SECRETS_MANAGER' ]]" "secrets-manager.sh should be executable"
|
||||
}
|
||||
|
||||
test_help_option() {
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" --help 2>&1) &&
|
||||
assert_contains "$output" "TSYS Secrets Manager" "Help should contain project name" &&
|
||||
assert_contains "$output" "Usage:" "Help should contain usage information"
|
||||
}
|
||||
|
||||
test_version_option() {
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" --version 2>&1) &&
|
||||
assert_contains "$output" "version" "Version output should contain 'version'"
|
||||
}
|
||||
|
||||
test_config_file_validation() {
|
||||
# Test with non-existent config file
|
||||
assert_command_failure "'$SECRETS_MANAGER' --config /nonexistent/config.conf test" \
|
||||
"Should fail with non-existent config file"
|
||||
}
|
||||
|
||||
test_config_file_loading() {
|
||||
# Test with valid test config
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" --config "$TEST_CONFIG" test 2>&1 || true) &&
|
||||
assert_contains "$output" "Loading configuration" "Should attempt to load config file"
|
||||
}
|
||||
|
||||
test_install_command_structure() {
|
||||
# Test install command without actually installing
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" install 2>&1 || true) &&
|
||||
assert_contains "$output" "Bitwarden CLI" "Install command should mention Bitwarden CLI"
|
||||
}
|
||||
|
||||
test_missing_command_error() {
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" 2>&1 || true) &&
|
||||
assert_contains "$output" "No command specified" "Should show error for missing command"
|
||||
}
|
||||
|
||||
test_invalid_command_error() {
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" invalidcommand 2>&1 || true) &&
|
||||
assert_contains "$output" "Unknown option" "Should show error for invalid command"
|
||||
}
|
||||
|
||||
test_get_command_requires_secret_name() {
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" get 2>&1 || true) &&
|
||||
assert_contains "$output" "Secret name required" "Get command should require secret name"
|
||||
}
|
||||
|
||||
test_script_error_codes() {
|
||||
# Test that script uses proper exit codes
|
||||
local exit_code
|
||||
|
||||
# Test invalid command
|
||||
"$SECRETS_MANAGER" invalidcommand >/dev/null 2>&1 || exit_code=$?
|
||||
assert_equals "1" "$exit_code" "Invalid command should exit with code 1"
|
||||
|
||||
# Test missing config file
|
||||
"$SECRETS_MANAGER" --config /nonexistent/config.conf test >/dev/null 2>&1 || exit_code=$?
|
||||
assert_equals "10" "$exit_code" "Missing config should exit with code 10"
|
||||
}
|
||||
|
||||
test_logging_functionality() {
|
||||
# Run a command that should generate logs
|
||||
"$SECRETS_MANAGER" --help >/dev/null 2>&1
|
||||
|
||||
# Check if log file is created (script creates logs for most operations)
|
||||
if [[ -f "$TEST_LOG" ]]; then
|
||||
return 0
|
||||
else
|
||||
# Some operations might not create logs, so this is a soft test
|
||||
log_warn "Log file not created - this may be normal for help command"
|
||||
return 0
|
||||
fi
|
||||
}
|
||||
|
||||
test_cleanup_functionality() {
|
||||
# Test that cleanup doesn't crash
|
||||
assert_command_success "unset BW_SESSION 2>/dev/null || true" \
|
||||
"Cleanup should handle missing session gracefully"
|
||||
}
|
||||
|
||||
test_config_file_security() {
|
||||
# Ensure test config file has appropriate permissions
|
||||
local perms
|
||||
perms=$(stat -c "%a" "$TEST_CONFIG" 2>/dev/null || echo "644")
|
||||
|
||||
# Config file should be readable by owner (we created it, so this should pass)
|
||||
if [[ "$perms" =~ ^[67][0-7][0-7]$ ]]; then
|
||||
return 0
|
||||
else
|
||||
log_warn "Config file permissions: $perms (consider restricting to 600)"
|
||||
return 0 # Don't fail test, just warn
|
||||
fi
|
||||
}
|
||||
|
||||
test_bitwarden_dependency_check() {
|
||||
local output
|
||||
# Test without Bitwarden CLI installed (if not already installed)
|
||||
if ! command -v bw >/dev/null 2>&1; then
|
||||
output=$(timeout 10 "$SECRETS_MANAGER" --config "$TEST_CONFIG" test 2>&1 || true)
|
||||
assert_contains "$output" "not installed" "Should detect missing Bitwarden CLI"
|
||||
else
|
||||
log_info "Bitwarden CLI already installed - skipping dependency check test"
|
||||
return 0
|
||||
fi
|
||||
}
|
||||
|
||||
# Integration tests (require actual Bitwarden setup)
|
||||
test_integration_bitwarden_config() {
|
||||
# Only run if we have a real config file
|
||||
if [[ -f "${SCRIPT_DIR}/bitwarden-config.conf" ]]; then
|
||||
log_info "Found real config file - running integration test"
|
||||
local output
|
||||
output=$(timeout 10 "$SECRETS_MANAGER" test 2>&1 || true)
|
||||
# Don't assert success since we may not have valid credentials
|
||||
# Just check that it attempts the operation
|
||||
assert_contains "$output" "Bitwarden" "Should attempt Bitwarden operations"
|
||||
else
|
||||
log_info "No real config file found - skipping integration test"
|
||||
return 0
|
||||
fi
|
||||
}
|
||||
|
||||
# Performance tests
|
||||
test_script_startup_time() {
|
||||
local start_time end_time duration
|
||||
start_time=$(date +%s%N)
|
||||
"$SECRETS_MANAGER" --help >/dev/null 2>&1
|
||||
end_time=$(date +%s%N)
|
||||
duration=$(( (end_time - start_time) / 1000000 )) # Convert to milliseconds
|
||||
|
||||
# Script should start in reasonable time (less than 5 seconds)
|
||||
if [[ $duration -lt 5000 ]]; then
|
||||
return 0
|
||||
else
|
||||
log_warn "Script startup took ${duration}ms (expected < 5000ms)"
|
||||
return 0 # Don't fail, just warn
|
||||
fi
|
||||
}
|
||||
|
||||
# Vendor integration tests
|
||||
test_vendor_compatibility() {
|
||||
# Test that script works when called from different directories
|
||||
local temp_dir
|
||||
temp_dir=$(mktemp -d)
|
||||
|
||||
pushd "$temp_dir" >/dev/null
|
||||
local output
|
||||
output=$("$SECRETS_MANAGER" --help 2>&1)
|
||||
popd >/dev/null
|
||||
|
||||
rmdir "$temp_dir"
|
||||
|
||||
assert_contains "$output" "TSYS Secrets Manager" \
|
||||
"Script should work when called from different directory"
|
||||
}
|
||||
|
||||
# Main test runner
|
||||
run_all_tests() {
|
||||
log_info "Starting TSYS Secrets Manager Test Suite"
|
||||
echo "========================================"
|
||||
|
||||
setup_test_environment
|
||||
|
||||
# Basic functionality tests
|
||||
run_test "Script exists and is executable" test_script_exists_and_executable
|
||||
run_test "Help option works" test_help_option
|
||||
run_test "Version option works" test_version_option
|
||||
run_test "Config file validation" test_config_file_validation
|
||||
run_test "Config file loading" test_config_file_loading
|
||||
run_test "Install command structure" test_install_command_structure
|
||||
run_test "Missing command error" test_missing_command_error
|
||||
run_test "Invalid command error" test_invalid_command_error
|
||||
run_test "Get command validation" test_get_command_requires_secret_name
|
||||
run_test "Script error codes" test_script_error_codes
|
||||
run_test "Logging functionality" test_logging_functionality
|
||||
run_test "Cleanup functionality" test_cleanup_functionality
|
||||
run_test "Config file security" test_config_file_security
|
||||
run_test "Bitwarden dependency check" test_bitwarden_dependency_check
|
||||
|
||||
# Integration tests
|
||||
run_test "Integration: Bitwarden config" test_integration_bitwarden_config
|
||||
|
||||
# Performance tests
|
||||
run_test "Script startup time" test_script_startup_time
|
||||
|
||||
# Vendor compatibility tests
|
||||
run_test "Vendor compatibility" test_vendor_compatibility
|
||||
|
||||
cleanup_test_environment
|
||||
|
||||
# Print results
|
||||
echo "========================================"
|
||||
log_info "Test Results:"
|
||||
echo " Total tests run: $TESTS_RUN"
|
||||
echo " Tests passed: $TESTS_PASSED"
|
||||
echo " Tests failed: $TESTS_FAILED"
|
||||
|
||||
if [[ $TESTS_FAILED -gt 0 ]]; then
|
||||
echo ""
|
||||
log_error "Failed tests:"
|
||||
for failure in "${TEST_FAILURES[@]}"; do
|
||||
echo " - $failure"
|
||||
done
|
||||
return 1
|
||||
else
|
||||
echo ""
|
||||
log_success "All tests passed!"
|
||||
return 0
|
||||
fi
|
||||
}
|
||||
|
||||
# Command line interface
|
||||
show_usage() {
|
||||
cat <<EOF
|
||||
TSYS Secrets Manager Test Suite
|
||||
|
||||
Usage:
|
||||
$0 [OPTIONS] [COMMAND]
|
||||
|
||||
Commands:
|
||||
run Run all tests (default)
|
||||
setup Setup test environment only
|
||||
cleanup Cleanup test environment only
|
||||
list List available test functions
|
||||
|
||||
Options:
|
||||
-h, --help Show this help message
|
||||
-v, --verbose Enable verbose output
|
||||
--ci Run in CI mode (no colors)
|
||||
|
||||
Examples:
|
||||
$0 # Run all tests
|
||||
$0 run # Run all tests
|
||||
$0 setup # Setup test environment
|
||||
$0 cleanup # Cleanup test files
|
||||
EOF
|
||||
}
|
||||
|
||||
list_tests() {
|
||||
echo "Available test functions:"
|
||||
declare -F | grep "test_" | sed 's/declare -f / - /'
|
||||
}
|
||||
|
||||
main() {
|
||||
local command="run"
|
||||
local verbose=false
|
||||
|
||||
while [[ $# -gt 0 ]]; do
|
||||
case $1 in
|
||||
-h|--help)
|
||||
show_usage
|
||||
exit 0
|
||||
;;
|
||||
-v|--verbose)
|
||||
set -x
|
||||
verbose=true
|
||||
shift
|
||||
;;
|
||||
--ci)
|
||||
CI=true
|
||||
shift
|
||||
;;
|
||||
run|setup|cleanup|list)
|
||||
command="$1"
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
echo "Unknown option: $1"
|
||||
show_usage
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
case "$command" in
|
||||
run)
|
||||
run_all_tests
|
||||
;;
|
||||
setup)
|
||||
setup_test_environment
|
||||
;;
|
||||
cleanup)
|
||||
cleanup_test_environment
|
||||
;;
|
||||
list)
|
||||
list_tests
|
||||
;;
|
||||
*)
|
||||
echo "Unknown command: $command"
|
||||
show_usage
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
}
|
||||
|
||||
# Handle script being sourced vs executed
|
||||
if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
|
||||
main "$@"
|
||||
fi
|
||||
Reference in New Issue
Block a user