Doctor plugin checks: implement health check classes and documentation
Implement remediation-aware health checks across all Doctor plugin modules (Agent, Attestor, Auth, BinaryAnalysis, Compliance, Crypto, Environment, EvidenceLocker, Notify, Observability, Operations, Policy, Postgres, Release, Scanner, Storage, Vex) and their backing library counterparts (AI, Attestation, Authority, Core, Cryptography, Database, Docker, Integration, Notify, Observability, Security, ServiceGraph, Sources, Verification). Each check now emits structured remediation metadata (severity, category, runbook links, and fix suggestions) consumed by the Doctor dashboard remediation panel. Also adds: - docs/doctor/articles/ knowledge base for check explanations - Advisory AI search seed and allowlist updates for doctor content - Sprint plan for doctor checks documentation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
master
120
docs/doctor/articles/crypto/gost.md
Normal file
120
docs/doctor/articles/crypto/gost.md
Normal file
@@ -0,0 +1,120 @@
|
||||
---
|
||||
checkId: check.crypto.gost
|
||||
plugin: stellaops.doctor.crypto
|
||||
severity: fail
|
||||
tags: [crypto, gost, russia, compliance]
|
||||
---
|
||||
# GOST Algorithm Availability
|
||||
|
||||
## What It Checks
|
||||
Verifies that GOST cryptographic algorithms are available for Russian deployments. The check validates two layers:
|
||||
|
||||
**Layer 1 - GOST engine detection:**
|
||||
Checks whether the OpenSSL GOST engine is loaded by looking for the engine shared object at:
|
||||
- A custom path configured via `Crypto:Gost:EnginePath`
|
||||
- Common system paths: `/usr/lib/x86_64-linux-gnu/engines-{3,1.1}/gost.so`, `/usr/lib64/engines-{3,1.1}/gost.so`
|
||||
|
||||
**Layer 2 - Algorithm availability** (only if engine is loaded):
|
||||
Verifies the following GOST algorithms are accessible:
|
||||
- **GOST R 34.10-2012-256** (digital signature, 256-bit)
|
||||
- **GOST R 34.10-2012-512** (digital signature, 512-bit)
|
||||
- **GOST R 34.11-2012-256** (Stribog hash, 256-bit)
|
||||
- **GOST R 34.11-2012-512** (Stribog hash, 512-bit)
|
||||
- **GOST R 34.12-2015** (Kuznyechik block cipher)
|
||||
- **GOST 28147-89** (Magma legacy block cipher)
|
||||
|
||||
| Condition | Result |
|
||||
|---|---|
|
||||
| GOST engine not loaded | Fail |
|
||||
| Engine loaded but some algorithms missing | Warn |
|
||||
| Engine loaded and all algorithms available | Pass |
|
||||
|
||||
Evidence collected: `CryptoProfile`, `GostEngineLoaded`, `AvailableAlgorithms`, `MissingAlgorithms`, `RequiredAlgorithms`.
|
||||
|
||||
The check only runs when `Crypto:Profile` or `Cryptography:Profile` contains "gost", "russia", or equals "ru".
|
||||
|
||||
## Why It Matters
|
||||
Russian regulatory requirements mandate the use of GOST cryptographic algorithms for government and many commercial deployments. Without GOST algorithm support, the platform cannot create compliant digital signatures or encrypt data according to Russian standards. This blocks deployment in regulated Russian environments and may violate data protection requirements.
|
||||
|
||||
## Common Causes
|
||||
- OpenSSL GOST engine not installed on the system
|
||||
- GOST engine not configured in `openssl.cnf`
|
||||
- Missing `gost-engine` package
|
||||
- GOST engine version too old (missing newer algorithms)
|
||||
- GOST engine installed but algorithm disabled in configuration
|
||||
- Incomplete GOST engine installation
|
||||
|
||||
## How to Fix
|
||||
|
||||
### Docker Compose
|
||||
```bash
|
||||
# Check if GOST engine is available
|
||||
docker compose exec gateway openssl engine gost -c 2>/dev/null || echo "GOST engine not found"
|
||||
|
||||
# Install GOST engine in the container (add to Dockerfile for persistence)
|
||||
# For Debian/Ubuntu based images:
|
||||
# RUN apt-get install -y libengine-gost-openssl1.1
|
||||
|
||||
# Set crypto profile
|
||||
# Crypto__Profile=ru
|
||||
# Crypto__Gost__EnginePath=/usr/lib/x86_64-linux-gnu/engines-3/gost.so
|
||||
|
||||
docker compose restart gateway
|
||||
```
|
||||
|
||||
### Bare Metal / systemd
|
||||
```bash
|
||||
# Install GOST engine (Debian/Ubuntu)
|
||||
sudo apt install libengine-gost-openssl1.1
|
||||
|
||||
# Or install from source
|
||||
git clone https://github.com/gost-engine/engine
|
||||
cd engine && mkdir build && cd build
|
||||
cmake .. && make && sudo make install
|
||||
|
||||
# Configure OpenSSL to load GOST engine
|
||||
# Add to /etc/ssl/openssl.cnf:
|
||||
# [gost_section]
|
||||
# engine_id = gost
|
||||
# default_algorithms = ALL
|
||||
|
||||
# Verify engine is loaded
|
||||
openssl engine gost -c
|
||||
|
||||
# Configure StellaOps GOST profile
|
||||
stella crypto profile set --profile ru
|
||||
|
||||
# In appsettings.json:
|
||||
# "Crypto": { "Profile": "ru" }
|
||||
|
||||
sudo systemctl restart stellaops-platform
|
||||
```
|
||||
|
||||
### Kubernetes / Helm
|
||||
```yaml
|
||||
# values.yaml
|
||||
crypto:
|
||||
profile: ru
|
||||
gost:
|
||||
enginePath: /usr/lib/x86_64-linux-gnu/engines-3/gost.so
|
||||
```
|
||||
|
||||
```bash
|
||||
# Verify in pod
|
||||
kubectl exec deploy/stellaops-gateway -- openssl engine gost -c
|
||||
|
||||
# Use a base image that includes GOST engine support
|
||||
# Or mount the engine as a volume
|
||||
helm upgrade stellaops ./charts/stellaops -f values.yaml
|
||||
```
|
||||
|
||||
## Verification
|
||||
```
|
||||
stella doctor run --check check.crypto.gost
|
||||
```
|
||||
|
||||
## Related Checks
|
||||
- `check.crypto.certchain` — certificates in GOST deployments should use GOST signature algorithms
|
||||
- `check.crypto.fips` — FIPS and GOST are mutually exclusive regional crypto profiles
|
||||
- `check.crypto.sm` — SM (Chinese) is another regional crypto profile with similar structure
|
||||
- `check.crypto.hsm` — GOST keys may be stored in an HSM with GOST support
|
||||
Reference in New Issue
Block a user