DevOps Academy

Security & Secrets

DevSecOps בפועל: IAM least-privilege, סריקת images, SAST, secrets management ו-network hardening

תיאוריה

⏱ ~60 דקות

Security בשוק DevOps הישראלי — DevSecOps כמקצוע

Security מופיע ב-2.4% ממשרות DevOps בישראל כהגדרה מפורשת — אבל בפועל כל משרת DevOps ב-2026 כוללת אחריות אבטחה. הסיבה: הפרצות הגדולות (Capital One 2019, SolarWinds 2020, Log4Shell 2021) קרו בתשתית שDevOps engineers ניהלו. הציפייה מהשוק:

- **IAM least privilege** — לא AdministratorAccess לכל application
- **Container image scanning** — לא לדפלוי images עם CVEs קריטיים
- **Secrets לא ב-git** — גיט הוא public history לעולם
- **SAST/DAST בCI/CD** — security scan בכל PR, לא רק לפני release
- **Network segmentation** — production לא נגיש ישירות מ-dev

נתון מ-audit_report.json: aws.devsecops_iam_policies הוא review_queue item מ-session 1 — נושא שזוהה כפער.

IAM Least Privilege — production gap קריטי

פער production

**production gap: IAM least-privilege policies for application roles**

**Anti-pattern נפוץ:**

# מה שרואים בחברות רבות
aws iam attach-role-policy \
  --role-name MyAppRole \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess  # WRONG!

**Principle of Least Privilege:**
כל application role מקבל רק את ה-permissions שהיא צריכה — ולא יותר.

**IAM Policy לאפליקציית Node.js שקוראת מS3 וכותבת ל-SQS:**

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-company-uploads",
        "arn:aws:s3:::my-company-uploads/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "sqs:SendMessage",
        "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:eu-west-1:123456789:my-app-queue"
    },
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:eu-west-1:123456789:secret:prod/myapp/*"
    }
  ]
}

**IAM Access Analyzer — בדיקת פוליסות:**

# בדוק אם role מעניק גישה פומבית
aws accessanalyzer create-analyzer \
  --analyzer-name my-org-analyzer \
  --type ORGANIZATION

# בדוק policy ספציפי לפני apply
aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://policy.json

**aws iam simulate-principal-policy — בדיקת הרשאות:**

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789:role/MyAppRole \
  --action-names s3:DeleteBucket s3:GetObject \
  --resource-arns arn:aws:s3:::my-company-uploads
# מחזיר allowed/denied per action

Container Image Scanning — Trivy

פער production

**production gap: container image vulnerability scanning with Trivy**

Docker image שנבנה מ-node:18 שנה שעברה עלול להכיל עשרות CVEs. Trivy הוא הכלי הנפוץ ביותר לscan.

**Trivy local:**

# התקנה
brew install aquasecurity/trivy/trivy  # macOS
apt-get install trivy  # Ubuntu

# scan image מ-registry
trivy image ghcr.io/myorg/my-app:latest

# scan image מקומי
trivy image my-app:latest

# exit code 1 אם יש CVE מ-severity HIGH ומעלה
trivy image --exit-code 1 --severity HIGH,CRITICAL my-app:latest

# פלט JSON לניתוח
trivy image --format json --output results.json my-app:latest

# scan Dockerfile
trivy config Dockerfile

# scan Terraform files
trivy config ./terraform/

**Trivy בGitHub Actions:**

- name: Scan Docker image for vulnerabilities
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ghcr.io/myorg/my-app:${{ github.sha }}
    format: sarif
    output: trivy-results.sarif
    severity: HIGH,CRITICAL
    exit-code: '1'  # fail CI if HIGH/CRITICAL found

- name: Upload scan results to GitHub Security
  uses: github/codeql-action/upload-sarif@v2
  if: always()  # גם אם scan נכשל
  with:
    sarif_file: trivy-results.sarif

**Trivy vs Snyk vs Grype:**
- Trivy: open source, מהיר, תומך images + IaC + git repos, פופולרי ב-GitHub Actions
- Snyk: SaaS, UI יפה, IDE plugins, מחיר לחברות גדולות
- Grype (Anchore): open source, דומה לTrivy, database מהיר

בחיר ב-2026: Trivy כברירת מחדל, Snyk כשצריך ניהול centralized.

Secrets ב-git — Prevention ו-Detection

פער production

**production gap: preventing secrets from entering git history**

פעם שsecret נכנס ל-git — הוא קיים בhistory לנצח גם אחרי git rm. גיטהאב סורק repos ל-credential patterns ומתריע, אבל עדיף למנוע.

**git-secrets — מניעת commit:**

brew install git-secrets
git secrets --install  # הוסף hooks ל-repo
git secrets --register-aws  # פטרנים של AWS keys
git secrets --scan  # scan על כל ה-repo

**gitleaks — scan על history קיים:**

# scan על ה-repo כולו
gitleaks detect --source . --report-format json

# scan על PR (pre-commit mode)
gitleaks protect --staged

# GitHub Actions
- name: Detect secrets
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

**Pre-commit hook (local):**

# .git/hooks/pre-commit
#!/bin/bash
gitleaks protect --staged --redact --config .gitleaks.toml || {
  echo 'ERROR: Potential secret detected! Fix before committing.'
  exit 1
}

**אם secret כבר נכנס:**

# 1. ROTATE את ה-credential מיד (לפני כל דבר אחר)
# 2. הסר מה-history עם BFG Repo Cleaner
bfg --delete-files config_with_secret.txt
bfg --replace-text secrets.txt
git reflog expire --expire=now --all
git gc --prune=now --aggressive

# 3. Force push (אחרי תיאום עם הצוות)
git push --force --all

**חשוב:** force push לא מוחק cache של GitHub/GitLab ב-forks קיימים. Rotation הוא הפעולה הקריטית.

SAST בCI/CD — Static Analysis Security Testing

SAST בודק קוד סטטית לפגיעויות — SQL injection, XSS, hardcoded credentials, vulnerable dependencies.

**Semgrep — SAST מהיר ופתוח:**

# התקנה
pip install semgrep

# scan בrules מובנות
semgrep --config=auto .

# scan ב-OWASP top 10 rules
semgrep --config=p/owasp-top-ten .

# scan rules ספציפיות
semgrep --config=p/python --config=p/nodejs .

# GitHub Actions
- name: SAST with Semgrep
  uses: semgrep/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/python
      p/secrets
  env:
    SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

**npm audit / pip-audit — dependency vulnerabilities:**

# Node.js
npm audit --audit-level=high  # exit 1 אם HIGH CVE
npm audit fix  # auto-fix

# Python
pip install pip-audit
pip-audit --vulnerability-service pypi
pip-audit -r requirements.txt

# GitHub Actions — dependabot (אוטומטי)
# .github/dependabot.yml:
version: 2
updates:
- package-ecosystem: npm
  directory: /
  schedule:
    interval: weekly
  open-pull-requests-limit: 5

**CodeQL (GitHub Advanced Security):**

- uses: github/codeql-action/init@v2
  with:
    languages: javascript, python

- uses: github/codeql-action/analyze@v2
  with:
    category: /language:javascript

CodeQL חזק מאוד על SQL injection, path traversal, command injection — מוצא vulnerabilities שSemgrep מפספס.

Network Security — Security Groups, NACLs ו-VPC segmentation

פער production

**production gap: AWS VPC network segmentation**

Network segmentation = הגבלת מי יכול לדבר עם מי ב-network. בAWS:

**Security Group (SG) — stateful firewall ל-resource:**

# SG לweb servers: port 443 מ-anywhere
aws ec2 create-security-group \
  --group-name web-sg \
  --description "Web servers - HTTPS only" \
  --vpc-id vpc-12345

aws ec2 authorize-security-group-ingress \
  --group-id sg-web \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# SG לDB: port 5432 רק מ-app servers SG
aws ec2 authorize-security-group-ingress \
  --group-id sg-db \
  --protocol tcp \
  --port 5432 \
  --source-group sg-app  # רק מ-app SG, לא IP!

**הכלל:** DB servers לא מקבלים traffic ישיר מהאינטרנט — רק מ-app servers SG. App servers לא מקבלים SSH ישיר — רק מ-bastion SG.

**NACL (Network ACL) — stateless firewall ל-subnet:**

# חסום outbound traffic מ-DB subnet לאינטרנט
aws ec2 create-network-acl-entry \
  --network-acl-id acl-db \
  --rule-number 100 \
  --protocol -1 \
  --rule-action deny \
  --egress \
  --cidr-block 0.0.0.0/0

**VPC Flow Logs — audit trail:**

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-destination arn:aws:logs:...:log-group:vpc-flow-logs

Flow Logs מאפשרים לזהות lateral movement (תוקף שמתקדם מserver לserver) אחרי incident.

Kubernetes Security — Pod Security, RBAC ו-Network Policies

פער production

**production gap: Kubernetes RBAC and Network Policies**

**RBAC — מי יכול לעשות מה ב-cluster:**

# Role (namespace-scoped) — מה מותר
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
# RoleBinding — למי לתת את ה-Role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: ServiceAccount
  name: monitoring-agent
  namespace: monitoring
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

**NetworkPolicy — הגבלת traffic בין Pods:**

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: my-app  # רק my-app Pods
    ports:
    - port: 5432

**Pod Security Standards:**

# Namespace annotation — enforce restricted policy
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.28

restricted policy: מחייב non-root user, drops all capabilities, מונע privileged containers.

**Admission controllers:**
- OPA/Gatekeeper: policy-as-code, מאפשר custom rules
- Kyverno: Kubernetes-native policy engine
- Falco: runtime security — מזהה syscalls חשודים


תרגול מעשי

1.

2.

3.


שאלות חיבור

חבר את מה שלמדת בנושא זה לנושאים קודמים. אין תשובה אחת נכונה — חשיבה ביקורתית היא המטרה.

שאלת חיבור 1

Git Advanced (topic #2) לימד pre-commit hooks ו-GitHub Actions (topic #8). כיצד שניהם יוצרים defense-in-depth למניעת secrets ב-git? הסבר: (1) מה ה-pre-commit hook שמונע secrets בlocal לפני push, (2) מה ה-CI/CD step שסורק secrets ב-PR לפני merge, ו-(3) מה קורה אם secret עבר את שני השכבות ונכנס ל-main.

מחבר ל:
Git Advanced

שאלת חיבור 2

AWS (topic #6) לימד Secrets Manager ו-IAM. Kubernetes (topic #9) לימד Secrets ו-RBAC. הסבר את האסטרטגיה המלאה לניהול סודות ב-Kubernetes cluster שרץ על EKS: (1) מה הבעיה עם K8s Secrets הרגילים, (2) כיצד External Secrets Operator מחבר בין K8s לAWS Secrets Manager, ו-(3) כיצד IRSA (IAM Roles for Service Accounts) מאפשר גישה לSecrets Manager בלי credentials ב-cluster.

מחבר ל:
AWS (reinforce)

מוכן לבחינה?

בצע הערכה תיאורטית, תרגול CLI ושאלות חיבור כדי לסיים את הנושא.