then if its node based project then do npm install so it will download all dependency

npm install

Its node based project so need to install cyclonedx to generate SBOM so we install it 

sudo npm install -g cyclonedx-bom

now to generate SBOm from package.json to sbom.xml do

cyclonedx-bom -o bom.xml

Now the generated sbom.xml file is not in human redable format so we will upload it in dependency-track tool which in starting we have run using docker container.

command for generate sbom in jenkins pipeline

syft dir:. -o cyclonedx-json > sbom.json
Ye command current directory ke packages scan karke sbom.json file banata hai in CycloneDX format.

Or ALternative

trivy fs --format cyclonedx --output sbom.json .

Command to generate and SBOM and scan in jenkins pipeline
Generate SBOM
syft dir:. -o cyclonedx-json > sbom.json
Scan SBOM / Vulnerabilities
grype sbom:sbom.json

(Alternative tools)

Using Trivy for both:
trivy fs --format cyclonedx --output sbom.json .
trivy sbom sbom.json

/

for sonar-scanning commands for jenkins pipeline

🔹 For Maven Project
mvn sonar:sonar \
  -Dsonar.projectKey=your_project_key \
  -Dsonar.host.url=http://your-sonarqube-server:9000 \
  -Dsonar.login=your_token

🔹 For Gradle Project

./gradlew sonarqube \
  -Dsonar.projectKey=your_project_key \
  -Dsonar.host.url=http://your-sonarqube-server:9000 \
  -Dsonar.login=your_token

🔹 For Generic / Other Projects (using Sonar Scanner CLI)

sonar-scanner \
  -Dsonar.projectKey=your_project_key \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://your-sonarqube-server:9000 \
  -Dsonar.login=your_token

✅ Short tip:
Use sonar-scanner for non-Maven/Gradle projects — bas token aur URL sahi do.

for Owasp dependency scan

🔹 For CLI (Generic Projects)
dependency-check.sh --project "MyProject" --scan . --format HTML --out reports/

🔹 For Maven Projects
mvn org.owasp:dependency-check-maven:check

🔹 For Gradle Projects
./gradlew dependencyCheckAnalyze


✅ Short tip:
Output report reports/dependency-check-report.html ya target/dependency-check-report.html mein milta hai.

For SCA (Software Composition Analysis) tools

🔹 Using Trivy (lightweight & popular)
trivy fs . --scanners vuln,secret,license -f table -o sca-report.txt

👉 Scans your source code/dependencies for vulnerabilities, secrets, and license issues.

🔹 Using Syft + Grype combo
syft dir:. -o cyclonedx-json > sbom.json
grype sbom:sbom.json -o table > sca-report.txt

👉 Syft creates SBOM, Grype scans it for vulnerabilities

🔹 Using OWASP Dependency-Check (for Maven/Gradle)
mvn org.owasp:dependency-check-maven:check

and for GRADLE
./gradlew dependencyCheckAnalyze

✅ Short tip:
Syft + Grype or Trivy = modern, fast SCA tools;
OWASP Dependency-Check = traditional Java-based SCA.

for trufflehog Use

Here are the short commands for TruffleHog (for secret scanning) 👇

🔹 Scan Local Directory
trufflehog filesystem .

🔹 Scan a Git Repository (local or remote)
trufflehog git file:///path/to/repo


or

trufflehog git https://github.com/your-org/your-repo.git

🔹 Scan with Output Report
trufflehog filesystem . --json > trufflehog-report.json


✅ Short tip:
Use TruffleHog to detect secrets, keys, tokens etc. in code or commit history — works great in CI/CD pipelines like Jenkins too.

owasp Zap DAST scanning

🔹 Quick Active Scan (CLI)

zap.sh -cmd -quickurl http://your-target-url -quickout zap-report.html

(Windows ke liye:)

zap.bat -cmd -quickurl http://your-target-url -quickout zap-report.html

🔹 Baseline Scan (recommended for CI/CD like Jenkins)

zap-baseline.py -t http://your-target-url -r zap-baseline-report.html

🔹 Full Active Scan

zap-full-scan.py -t http://your-target-url -r zap-fullscan-report.html

✅ Short tip:

• Baseline scan → safe (no attack, passive check)

• Full scan → aggressive (tests vulnerabilities deeply)

• Reports usually save as HTML (viewable in Jenkins artifacts).

You said:

zap-full-scan.py this .py file we need to instal or it is auto added while installing tool ?

ChatGPT said:

Good question 👏

When you install OWASP ZAP, those Python scripts like zap-full-scan.py, zap-baseline.py, and zap-api-scan.py are automatically included — you don’t need to install them separately ✅

Here’s how it works:

• These scripts come bundled with the official ZAP Docker image or the ZAP installation package.

• If you’re using ZAP via Docker (recommended for CI/CD) → you can run them directly, e.g. 👇

    docker run -t owasp/zap2docker-stable zap-full-scan.py -t http://your-target-url -r report.html
  

• If you installed ZAP locally, they’ll be found inside your ZAP install directory, for example:

    /usr/share/zaproxy/
  

  or

    C:\Program Files\OWASP\Zed Attack Proxy\
  

✅ Short summary:
No need to install zap-full-scan.py separately — it’s part of OWASP ZAP (especially in Docker image or full installation).

You said:

there is few scan types in owasp zap whats that something like spider scan and other

ChatGPT said:

Great question 👍 — OWASP ZAP (Zed Attack Proxy) has multiple scan types, each serving a different purpose in the DAST process.
Here’s a short and clear breakdown in Hinglish + English 👇

🕷️ 1. Spider Scan

• Purpose: Crawls the target website to discover all URLs, links, and parameters.

• Think of it as: “Site map banata hai” before scanning.

• Command example:

    zap-cli spider http://your-target-url
  

⚡ 2. Active Scan

• Purpose: Actively attacks discovered URLs to find vulnerabilities (SQLi, XSS, etc.).

• Think of it as: “Actual penetration test” part.

• Command example:

    zap-cli active-scan http://your-target-url
  

🧭 3. Passive Scan

• Purpose: Analyzes HTTP traffic without attacking — safe scan.

• Think of it as: “Observation only, no damage.”

• Automatically runs whenever ZAP is proxying traffic.

📑 4. AJAX Spider

• Purpose: Special spider that can crawl JavaScript-heavy (AJAX / SPA) apps (e.g., React, Angular).

• Useful for: Modern web apps where normal spider misses dynamic links.

• Command example:

    zap-cli ajax-spider http://your-target-url
  

🧩 5. API Scan

• Purpose: Scans APIs (OpenAPI/Swagger/GraphQL).

• Command example:

    zap-api-scan.py -t http://your-api/swagger.json -f openapi -r api-report.html
  

✅ Quick Summary Table:

we have diff command for each in cicd jenkins pipeline or single command will do all ?

🔹 Option 1: Single Command (Recommended for CI/CD)

If you just want a complete scan (Spider + Active + Passive) automatically —
use ZAP’s ready-made scripts like these 👇

✅ Baseline scan (safe, quick, passive only)

zap-baseline.py -t http://your-target-url -r zap-baseline-report.html

• Does Spider + Passive Scan

• Safe for CI — no active attacks

✅ Full scan (complete DAST)

zap-full-scan.py -t http://your-target-url -r zap-fullscan-report.html

• Does Spider + Active + Passive Scan

• Recommended for nightly or staging scans

👉 So yes, these .py scripts are all-in-one commands — no need to run each scan type separately in CI/CD.

🔹 Option 2: Individual Commands (Advanced / Custom Flow)

If you want more control (for example, separate stages in Jenkins), you can run them manually:

zap-cli spider http://your-target-url
zap-cli active-scan http://your-target-url
zap-cli report -o zap-report.html -f html

But this is rarely needed unless you’re doing very fine-grained orchestration.

✅ Short Summary (Hinglish mein):

• CI/CD mein ek hi command kaafi hai → zap-baseline.py (safe) ya zap-full-scan.py (deep scan).

• Alag commands tabhi chahiye jab tum scan flow customize karna chahte ho (manual spider, selective attack, etc.).

what possibility scan result it will give us in output means what main check it will cover

Let’s break down what OWASP ZAP scan results actually cover — i.e., what kinds of issues or checks you’ll see in the output report (HTML, XML, JSON, etc.).

⚡ OWASP ZAP Scan Output – Main Checks Covered

🔹 1. Authentication & Session Issues

• Missing or weak login protection

• Session ID exposed in URL or cookies

• Insecure cookie flags (HttpOnly, Secure, SameSite) missing

• Predictable session tokens

🔹 2. Input Validation / Injection Attacks

• SQL Injection

• Cross-Site Scripting (XSS) – reflected, stored, or DOM-based

• Command Injection or Path Traversal

• LDAP / XML / NoSQL Injection (if applicable)

🔹 3. Cross-Site Request Forgery (CSRF)

• Detects forms or endpoints missing CSRF tokens

• Checks for weak anti-CSRF implementation

🔹 4. Security Headers Missing

• Missing headers like:

  • X-Frame-Options

  • X-Content-Type-Options

  • Content-Security-Policy

  • Strict-Transport-Security

• These headers prevent clickjacking, MIME sniffing, and other attacks

🔹 5. Sensitive Data Exposure

• Checks for:

  • Information leakage (e.g., stack traces, debug info)

  • Hardcoded secrets or API keys in responses

  • Exposed server banners (Server: Apache/2.4.7, etc.)

  • HTTP instead of HTTPS links

🔹 6. Broken Access Control

• Endpoints accessible without authentication

• Privilege escalation vulnerabilities

• Hidden URLs or admin paths exposed

🔹 7. Insecure Communication

• HTTP pages instead of HTTPS

• Weak SSL/TLS configuration (if configured with SSL plugin)

🔹 8. Miscellaneous Checks

• Redirects without validation

• Open redirects

• Form autocomplete enabled

• Misconfigured or open APIs

📊 Report Structure (Typical Output)

When you generate a ZAP report (zap-fullscan-report.html), you’ll see sections like:

• Alert Summary → High, Medium, Low, Informational

• Alert Details → Description, URL affected, parameter, evidence, and fix recommendation

• Statistics → Number of requests, time taken, scan progress

✅ Short summary (Hinglish mein):
OWASP ZAP tumhe mostly web app ke real-world security flaws batata hai — jaise:

XSS, SQLi, missing headers, CSRF, session flaws, info leaks, insecure cookies, access control issues, etc.

Would you like me to give you a sample Jenkins HTML report snippet (how it looks when attached as artifact)?

You said:

ok then what is this command and when to use if you have given then is it wrong ? zap-cli --api-key=$ZAP_API quick-scan --self-contained http://staging.my-app.com

ChatGPT said:

Ah yes 😄 — let me clarify this properly. That command you wrote is not wrong, it’s just a different way of running ZAP scans using the zap-cli tool instead of zap-full-scan.py or zap-baseline.py.

🔹 Command You Gave

zap-cli --api-key=$ZAP_API quick-scan --self-contained http://staging.my-app.com

🔹 Breakdown

• zap-cli → A Python CLI wrapper around ZAP (lets you control ZAP from command line easily)

• --api-key=$ZAP_API → Authenticates to ZAP API (needed if ZAP is running in daemon mode)

• quick-scan → Runs a simple scan (spider + active scan in one go)

• --self-contained → Launches a ZAP daemon in the background, runs the scan, and shuts it down automatically

• http://staging.my-app.com → Target URL

🔹 When to Use

• CI/CD / Jenkins pipelines → when you want a lightweight scan without manually starting ZAP GUI or daemon

• Quick checks / staging deployments → gives a faster overview of vulnerabilities

• Not for deep production testing → use zap-full-scan.py for thorough, full DAST

🔹 Key Differences vs zap-full-scan.py

✅ Short Summary:

• Not wrong — it’s a valid, quick way to scan in Jenkins.

• Use zap-cli quick-scan → for fast, self-contained scans.

• Use zap-full-scan.py → for thorough, production/staging scans with more coverage.

🔹 Humara Setup ka idea

1. Kafka cluster already chal raha hai (on-prem / Kubernetes me operator ke through / external service)?

2. Aapki consumer application (jo Kafka se data read karti hai) Kubernetes me deploy hai?

3. Topic ke partitions ka count aapne decide kar liya hai (maan lo 15 jaise humne discuss kiya tha)?

🔹 KEDA ke liye zaroori cheez

KEDA scaling ka kaam karega consumer lag ke basis par.
Iske liye hume KEDA ke scaler me ye info deni padti hai:

• Kafka bootstrap servers (kafka:9092 jaisa)

• Consumer group id (jo aapki app use karti hai)

• Topic name (rides)

• Thresholds (kitna lag hone par pods scale up/down honge)

• Max replicas (jo partitions ke barabar ya uske kareeb hoga)

🔹 Flow kya hoga

1. Aapke paas ek Deployment hoga consumer app ka.

2. Us Deployment par KEDA ek ScaledObject lagayega.

KEDA lag monitor karega aur Deployment ke replicas adjust karega.

Pehle Kafka ke basics clear karte hain (deployment aur design related), fir uspe KEDA ko chipka denge.

🟢 Step 1: Kafka ke Core Concepts (recap)

1. Topic → ek subject jisme messages store hote hain (e.g. rides)

2. Partition → topic ke andar parallel lanes (processing ke liye)

3. Broker → ek Kafka server (jo partitions ko store karta hai)

4. Replication → safety ke liye har partition ke multiple copies alag brokers par

5. Consumer Group → ek app/worker set jo topic ka data process karta hai

🟢 Step 2: Kafka Kubernetes me kaise deploy hota hai?

Kafka ko manually deploy karna mushkil hai, isliye log Operators use karte hain. Do common hain:

• Strimzi Kafka Operator (open source, k8s native)

• Confluent Operator (enterprise)

Sabse simple aur popular → Strimzi.

🟢 Step 3: Minimal Strimzi Kafka Cluster Example

# Kafka Cluster
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    version: 3.6.0
    replicas: 3  # 3 brokers
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
    config:
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      log.message.format.version: "3.6"
    storage:
      type: ephemeral
  zookeeper:
    replicas: 3
    storage:
      type: ephemeral
  entityOperator:
    topicOperator: {}
    userOperator: {}

🟢 Step 4: Kafka Topic Create with Strimzi

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: rides
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 15         # parallelism
  replicas: 3            # safety
  config:
    retention.ms: 604800000   # 7 days

🟢 Step 5: Kafka User (Consumer App ke liye)

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-consumer
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: rides
          patternType: literal
        operation: Read
      - resource:
          type: group
          name: my-consumer-group
          patternType: literal
        operation: Read

🟢 Step 6: Application Consumer Side

• Consumer app ko deploy karte waqt aapko dena hoga:

  • bootstrapServers = my-cluster-kafka-bootstrap:9092

  • topic = rides

  • group.id = my-consumer-group

  • username/password = my-consumer KafkaUser se

✅ Abhi tak result

• Aapke paas ek Kafka cluster (3 brokers + Zookeeper)

• Ek topic rides (15 partitions)

• Ek Kafka user (my-consumer) jo us topic se messages consume kar sakta hai

**Now We are getting Question in our mind jo pehle hona chaye tha par abhi huva but no worry

ye strimzi kya hai , kyu use kar rhe hai and uske use kar ne k fayde kya hai wo batado and any other information of strizi you think i need to know fir keda par aate hai**

🔹 Strimzi kya hai?

• Strimzi = Kafka Operator for Kubernetes

• Ek open-source CNCF project hai.

• Ye Kubernetes ke CRDs (Custom Resource Definitions) use karke Kafka manage karta hai.

• Matlab aap Kafka cluster ko asani se yaml likh kar bana, update aur manage kar sakte ho.

🔹 Strimzi kyu use karte hain? (fayde)

1. Easy Kafka Deployment

   • Normally Kafka setup karna tough hai (brokers, Zookeeper, configs).

   • Strimzi ke saath aap ek simple YAML likho → Kafka cluster deploy ho jata hai.

2. Self-healing & Auto management

   • Agar koi broker crash ho jaye → Strimzi automatically naya broker bana deta hai.

   • Broker IDs, configs, networking sab handle ho jata hai.

3. Topic & User as Kubernetes objects

   • KafkaTopic aur KafkaUser resources ke through topics/users manage kar sakte ho (YAML se hi).

   • ACLs (permissions) bhi declarative tareeke se define kar sakte ho.

4. Scaling & Rolling Updates

   • Brokers ko scale up/down karna YAML change karke easy ho jata hai.

   • Config updates rolling fashion me apply hote hain → downtime kam.

5. Security

   • TLS encryption, SASL authentication, ACL-based authorization → sab built-in.

6. Monitoring

   • Prometheus & Grafana integration ke saath aata hai → metrics aur monitoring easy ho jati hai.

🔹 Strimzi ke CRDs (jo aap use karoge)

• Kafka → cluster deploy karne ke liye

• KafkaTopic → topics manage karne ke liye

• KafkaUser → users manage karne ke liye

• KafkaConnect → Kafka Connect cluster banane ke liye

• KafkaMirrorMaker → cross-cluster replication ke liye

🔹 Kab use kare Strimzi?

• Agar aap Kubernetes pe Kafka run kar rahe ho → Strimzi best option hai.

• Agar aap cloud managed Kafka (jaise Confluent Cloud, AWS MSK, Azure EventHub) use karte ho → tab Strimzi ki zarurat nahi.

🔹 Limitations bhi hain

• Ye Kubernetes dependent hai (on-prem bare metal servers pe directly use nahi hoga).

• Agar aap already ek cloud provider ka managed Kafka le rahe ho (jaise AWS MSK), to Strimzi ki zarurat nahi.

• Large scale clusters me tuning karna thoda complex ho sakta hai (storage, networking).

✅ To Summarize

• Strimzi ek Kubernetes operator hai jo Kafka ko deploy/manage karna easy banata hai.

• Fayde: easy deployment, self-healing, security, monitoring, declarative config, YAML-based management.

• Ye aapko Kafka ko Kubernetes-native banata hai.

NEXT

Aap Strimzi use karke Kafka cluster banayenge → topic banayenge (rides, 15 partitions) → consumer app deploy karenge → aur uske upar KEDA lagayenge taaki pods auto-scale ho.

🔹 Ab KEDA ka role

1. KEDA Kafka ke consumer lag (pending messages) monitor karega.

2. Agar lag high hai → consumer app ke pods (Deployment replicas) scale up.

3. Agar lag kam hai → pods scale down (even 1 tak).

4. Iska max limit aap decide karenge (jo partitions count se zyada nahi hona chahiye).

🔹 KEDA ke liye do main YAML hote hain

1. Deployment → aapki consumer app

   • Ye Kafka se messages consume karegi

   • Normal k8s Deployment jaisa hi hoga

2. ScaledObject (KEDA ka resource)

   • Isme define hota hai scaling ka trigger (Kafka lag)

   • Isme set karte ho: bootstrap server, topic, consumer group, lag threshold, min/max replicas

🔹 Flow Example

Maan lo:

• Topic = rides

• Partitions = 15

• Consumer group = my-consumer-group

• Aap chahte ho pods min=1 se max=15 tak auto-scale karein

To jab traffic zyada hoga → pods 15 tak jayenge
Jab traffic kam hoga → pods 1 tak aa jayenge
Kafka ka load efficiently process hoga.

Now: Deployment + KEDA ScaledObject ka YAML

🟢 Step 1: Consumer App Deployment

Ye aapka Kafka consumer app hai jo topic rides se read karega. (Yahan example image liya hai, aap apni app ka image daloge)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kafka-consumer
  labels:
    app: kafka-consumer
spec:
  replicas: 1   # KEDA isko manage karega, aap manually replicas mat badhao
  selector:
    matchLabels:
      app: kafka-consumer
  template:
    metadata:
      labels:
        app: kafka-consumer
    spec:
      containers:
        - name: consumer
          image: myrepo/kafka-consumer:latest   # 👈 apna image
          env:
            - name: BOOTSTRAP_SERVERS
              value: "my-cluster-kafka-bootstrap:9092"  # Strimzi bootstrap service
            - name: TOPIC
              value: "rides"
            - name: GROUP_ID
              value: "my-consumer-group"
            - name: USERNAME
              valueFrom:
                secretKeyRef:
                  name: my-consumer   # Strimzi KafkaUser se aaya secret
                  key: sasl.jaas.config
            # ⚠️ Upar ka secret config aapke auth method ke hisaab se change hoga

🟢 Step 2: KEDA ScaledObject

Ye KEDA resource hai jo lag dekh ke replicas adjust karega.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaledobject
spec:
  scaleTargetRef:
    name: kafka-consumer   # 👈 Ye Deployment ka naam
  minReplicaCount: 1
  maxReplicaCount: 15      # 👈 Topic partitions = 15
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: my-cluster-kafka-bootstrap:9092
        consumerGroup: my-consumer-group
        topic: rides
        lagThreshold: "100"   # 👈 Agar 100 pending messages per partition se zyada hue to scale karega

🔹 Flow ab hoga:

1. Kafka me jab backlog (lag) > 100 messages per partition ho → KEDA pods increase karega.

2. Max pods = 15 (kyunki partitions = 15) → har pod ek partition le lega.

3. Jab backlog 0 ho → pods wapas 1 tak reduce ho jayenge.

🔹 Notes

• Aapko KEDA install karna hoga (helm install kedacore/keda)

• LagThreshold ko tune karna hoga (traffic ke hisaab se)

• Agar aap partitions future me badhate ho → maxReplicaCount bhi accordingly update karna hoga

• Auth config (SASL/PLAIN, TLS) aapke KafkaUser se aayega (jo Strimzi banayega)

Here are the most important fields to keep when designing policies around enforcement:

🔹 Process & Execution Context

• process.binary → the actual executable (/usr/bin/sleep, /bin/bash, etc.)

• process.arguments → arguments passed to the binary (e.g., sleep infinity)

• process.uid → which user ran the process (0 = root)

• process.cwd → working directory (sometimes important for distinguishing behavior)

• process.flags → useful for detecting execve, setuid, init process, etc.

🔹 Container / Pod Context

• process.pod.namespace → Kubernetes namespace

• process.pod.name → Pod name

• process.pod.container.name → Container name

• process.pod.container.image.name → Image name (docker.io/library/ubuntu:latest)

• process.pod.pod_labels → Kubernetes labels (for selecting workloads via policies)

• process.pod.workload_kind → Pod, Deployment, DaemonSet, etc.

🔹 Parent Process Context

• parent.binary → helps detect container runtimes or unexpected parent processes

• parent.exec_id → trace lineage of execution

🔹 Node / Cluster Context

• node_name → node where the event occurred

• node_labels → useful for scoping policies to node groups, zones, instance types, etc.

🔹 Event Metadata

• time → event timestamp (critical for audit trails)

• process.exec_id → unique identifier for correlation

• parent_exec_id → trace back execution chains

✅ In practice, the core fields most often used for enforcement are:

• Binary / arguments

• Pod namespace / name / labels

• Container image

• User (UID)

• Parent binary

• Node name (if node-specific policies are needed)

install tetragon CLI and move its binary to /usr/loval/bin/

# Download the latest tetra (Linux x86_64 example)
curl -L https://github.com/cilium/tetragon/releases/latest/download/tetra-linux-amd64.tar.gz -o tetra.tar.gz

# Extract and move to /usr/local/bin
tar -xvf tetra.tar.gz
sudo mv tetra /usr/local/bin/

# Verify
tetra version

now check logs

kubectl logs -f -n kube-system ds/tetragon -c export-stdout | tetra getevents -o compact

Jenkins requires Java in order to run, yet certain distributions don’t include this by default, and some Java versions are incompatible with Jenkins.

There are multiple Java implementations that you can use. OpenJDK is the most popular one at the moment, and we will use it in this guide.

Update the Debian apt repositories, install OpenJDK 11, and check the installation with the following commands:

Java install

sudo apt update

sudo apt install openjdk-11-jre

java -version

The commands for installing Jenkins are Run after installing JAVA only

curl -fsSL https://pkg.jenkins.io/debian/jenkins.io-2023.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null

echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

sudo apt-get update

sudo apt-get install jenkins

Start Jenkins

check status of jenkins

sudo systemctl status jenkins

we can enable Jenkins service if it's disabled.

sudo systemctl enable jenkins

we can start Jenkins if it's stopped by the command

sudo systemctl start jenkins

Installation of Docker and add it in sudoer group, add jenkins in sudoers grp

Docker installation command

sudo apt-get install docker.io

add docker in sudoers group
sudo usermod -aG docker $USER && newgrp docker

for jenkins pipeline add jenkins to docker group
sudo usermod -a -G docker jenkins