cybersecurity

Optimize Azure Traffic Flow with UDR

techhadoop azure , , , ,

Traffic Flow Through Azure Firewall via UDR

The UDR (User Defined Route) is the mechanism that forces all spoke traffic through Azure Firewall — overriding Azure’s default system routes which would otherwise send traffic directly between peered VNets, bypassing inspection entirely.

Why UDRs Are Necessary

Azure VNet peering by default creates direct routing between peered VNets — packets travel peer-to-peer without touching any intermediate device. This means without UDRs, a VM in Spoke 1 talking to a VM in Spoke 2 completely bypasses Azure Firewall:

Default behaviour (NO UDR):
  Spoke 1 VM (10.1.1.4) → Spoke 2 VM (10.2.1.4)
  System route: 10.2.0.0/16 → VNet peering (direct)
  Result: traffic bypasses firewall entirely 

With UDR applied to spoke subnet:
  Spoke 1 VM (10.1.1.4) → Spoke 2 VM (10.2.1.4)
  UDR overrides: 0.0.0.0/0 → 10.0.1.4 (Firewall private IP)
  Result: traffic hits firewall → inspected → forwarded

The UDR wins because custom routes always override system routes — Azure’s route selection priority is custom UDR first, then BGP routes, then system routes.

Route Table Structure

A route table is an Azure resource associated with one or more subnets. Every subnet that needs inspection gets the same core UDR:

Route Table: rt-spoke1-subnets
Associated to: Spoke 1 subnet A, Spoke 1 subnet B

Routes:
  Name              Prefix          Next hop type        Next hop IP
  ─────────────────────────────────────────────────────────────────
  force-to-fw       0.0.0.0/0       Virtual Appliance    10.0.1.4

Deployed via ARM / Bicep:

resource routeTable 'Microsoft.Network/routeTables@2023-04-01' = {
  name: 'rt-spoke1-subnets'
  location: location
  properties: {
    disableBgpRoutePropagation: true   // ← critical — explained below
    routes: [
      {
        name: 'force-to-firewall'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.1.4'   // Azure Firewall private IP
        }
      }
    ]
  }
}

// Associate with spoke subnet
resource subnetAssociation 'Microsoft.Network/virtualNetworks/subnets@2023-04-01' = {
  name: 'spoke1/snet-app'
  properties: {
    addressPrefix: '10.1.1.0/24'
    routeTable: {
      id: routeTable.id
    }
  }
}

The Three Traffic Paths

Path 1 — North-South Outbound (spoke VM → internet)

Step 1: Spoke 1 VM (10.1.1.4) sends packet to 8.8.8.8
Step 2: Subnet route table consulted
        UDR match: 0.0.0.0/0 → next hop 10.0.1.4 (Firewall)
Step 3: Packet arrives at Azure Firewall private IP
Step 4: Firewall evaluates application rules
        Rule: allow src=10.1.0.0/16 dest=*.google.com proto=HTTPS → ALLOW
Step 5: Firewall SNATs packet
        Source IP changed: 10.1.1.4 → Firewall public IP (20.x.x.x)
Step 6: Packet exits to internet from Firewall public IP
        Return traffic arrives at Firewall public IP
Step 7: Firewall translates back → forwards to 10.1.1.4

SNAT is automatic for internet-bound traffic — the spoke VM’s private IP is never exposed to the internet. Azure Firewall’s public IP is the only address the internet sees.

Path 2 — North-South Inbound (internet → spoke VM)

Step 1: External client sends to Firewall public IP 20.x.x.x:443
Step 2: Firewall DNAT rule fires:
        dest 20.x.x.x:443 → translated to 10.1.4.5:443 (spoke VM)
Step 3: Firewall forwards to 10.1.4.5 via VNet peering path
Step 4: Packet arrives at spoke VM — no public IP needed on VM
Step 5: VM responds to Firewall private IP (it sees FW as source)
        UDR on VM subnet ensures return goes back through Firewall
Step 6: Firewall forwards return to external client

Path 3 — East-West (spoke 1 VM → spoke 2 VM)

This is the most important path for security — lateral movement between spokes must be inspected:

Step 1: Spoke 1 VM (10.1.1.4) sends packet to Spoke 2 VM (10.2.1.8)
Step 2: Spoke 1 subnet route table consulted
        UDR: 0.0.0.0/0 → 10.0.1.4 (matches — more specific than system route)
Step 3: Packet arrives at Azure Firewall
Step 4: Firewall evaluates network rules
        Rule: allow src=10.1.0.0/16 dest=10.2.1.8 port=443 → ALLOW
        (or deny if no rule matches)
Step 5: Firewall forwards to 10.2.1.8 via peering to Spoke 2
Step 6: Spoke 2 subnet route table:
        UDR: 0.0.0.0/0 → 10.0.1.4
        Return traffic: 10.2.1.8 → 10.1.1.4
        UDR forces return through Firewall too
Step 7: Firewall forwards return packet to Spoke 1 VM

Both directions of every connection traverse the Firewall — request and response. This is essential for stateful inspection — if only one direction went through the Firewall, the session state table would be incomplete.

disableBgpRoutePropagation — Why It Matters

Every route table has a disableBgpRoutePropagation flag. On spoke subnets this must be set to true:

disableBgpRoutePropagation: false (default)
  → VPN Gateway pushes on-premises routes into spoke effective routes
  → Spoke VM sends on-premises traffic directly to Gateway
  → Bypasses Firewall for on-premises bound traffic ❌
disableBgpRoutePropagation: true (required for spoke subnets)
  → VPN Gateway routes suppressed on spoke subnets
  → Only UDR routes active: 0.0.0.0/0 → Firewall
  → All traffic including on-premises bound goes through Firewall ✅

Forgetting this setting is one of the most common misconfiguration errors in hub and spoke deployments — on-premises traffic silently bypasses the Firewall even though the UDR looks correct.

UDR on GatewaySubnet — On-Premises to Spoke

To inspect traffic arriving from on-premises destined for spoke VNets, a UDR must also be applied to the GatewaySubnet:

Route Table: rt-gateway-subnet
Associated to: GatewaySubnet
Routes:
  Name            Prefix           Next hop type       Next hop IP
  ────────────────────────────────────────────────────────────────
  to-spoke1       10.1.0.0/16      VirtualAppliance    10.0.1.4
  to-spoke2       10.2.0.0/16      VirtualAppliance    10.0.1.4
  to-spoke3       10.3.0.0/16      VirtualAppliance    10.0.1.4

Note this uses specific spoke prefixes rather than 0.0.0.0/0 — applying a default route to GatewaySubnet breaks the gateway’s ability to communicate with Azure control plane endpoints.

Effective Route Inspection

You can verify UDRs are working correctly by checking a VM’s effective routes in the Azure portal or CLI:

az network nic show-effective-route-table \
  --resource-group rg-spoke1 \
  --name vm-prod-01-nic \
  --output table
Source    State    Address Prefix    Next Hop Type       Next Hop IP
────────  ───────  ────────────────  ──────────────────  ──────────
Default   Active   10.1.0.0/16       VnetLocal
Default   Invalid  0.0.0.0/0         Internet            ← overridden
User      Active   0.0.0.0/0         VirtualAppliance    10.0.1.4  ✅
Default   Active   10.0.0.0/16       VNetPeering
Default   Active   10.2.0.0/16       VNetPeering

The default 0.0.0.0/0 → Internet system route shows as Invalid — it has been overridden by the custom UDR pointing to the Firewall. This confirms all traffic is force-tunnelled correctly.

Common Misconfiguration Pitfalls

Forgetting disableBgpRoutePropagation — gateway-learned routes override UDRs for on-premises prefixes, silently bypassing Firewall for hybrid traffic.

Missing return path UDR — if Spoke 2 subnet has no UDR, return traffic goes directly back to Spoke 1 via peering, creating an asymmetric routing loop that breaks TCP sessions.

Applying UDR to AzureBastionSubnet — Bastion requires direct internet connectivity for its management plane. A UDR with 0.0.0.0/0 → Firewall on AzureBastionSubnet breaks Bastion entirely. Bastion subnet must have no UDR or a very specific one that excludes Bastion management ranges.

Applying 0.0.0.0/0 UDR to GatewaySubnet — breaks gateway health probes and control plane communication. Always use specific spoke prefixes on GatewaySubnet, never a default route.

Firewall private IP not static — Azure Firewall’s private IP should be configured as static during deployment. If it changes, every UDR next-hop entry becomes invalid and traffic black-holes.

Key Takeaway

The UDR is a deceptively simple mechanism — a single route entry 0.0.0.0/0 → Virtual Appliance → 10.0.1.4 — that transforms Azure’s default direct peering behaviour into a fully inspected, security-enforced network. Applied correctly to every spoke subnet with disableBgpRoutePropagation enabled, it ensures no traffic — outbound internet, inbound DNAT, or lateral east-west — can bypass Azure Firewall, giving you complete visibility and control over your entire hub and spoke estate.

Understanding Azure DDoS Protection Standard

techhadoop azure , , , ,

Azure DDoS Protection Standard

Azure DDoS Protection Standard is a managed, always-on service that detects and mitigates volumetric, protocol, and application-layer DDoS attacks against your Azure public IP addresses — automatically, without any configuration changes during an attack.

The Three Attack Categories It Defends Against

Layer 3/4 — Volumetric attacks

These flood your network bandwidth with massive traffic volumes — UDP floods, ICMP floods, amplification attacks (DNS, NTP, memcached). Azure absorbs these at the network edge using its global 60+ Tbps scrubbing capacity, before the traffic ever reaches your VNet or gateway.

Layer 3/4 — Protocol attacks

These exhaust connection state tables on firewalls, load balancers, and gateways. SYN floods send millions of half-open TCP connections; Smurf attacks abuse ICMP broadcasts. DDoS Protection mitigates these by validating TCP handshakes and rate-limiting malformed packets at the edge.

Layer 7 — Resource layer attacks

HTTP floods, Slowloris, and application-specific attacks target your app’s compute rather than your bandwidth. DDoS Protection Standard alone does not fully mitigate Layer 7 attacks — these require Azure WAF on Application Gateway or Azure Front Door working alongside DDoS Protection. The two services are designed to be used together for full-stack protection.

How Adaptive Tuning Works

This is the core differentiator versus the free Basic tier. DDoS Protection Standard builds a per-public-IP traffic baseline using machine learning:

Normal Monday traffic profile for your VPN Gateway public IP:
  - Avg 2,000 packets/sec
  - Peak 8,000 packets/sec
  - Protocol mix: 70% TCP, 20% UDP, 10% ICMP
  - Geographic distribution: CA, US, EU
Attack detected when:
  - Packets jump to 4,000,000/sec  ← 500× normal
  - 99% from single ASN in one region
  - All UDP port 53 (DNS amplification)
Response: automatic mitigation within seconds
  - Rate limit traffic matching attack signature
  - Pass legitimate traffic through
  - Alert via Azure Monitor

Baselines are built per public IP, per protocol, per port — so the service understands what normal looks like for your VPN Gateway vs your Application Gateway vs your load balancer, and tuning is automatic as your traffic patterns change.

DDoS Protection Tiers Compared

FeatureBasic (free)Network (Standard)IP Protection
Always-on monitoring✅✅✅
Automatic attack mitigation✅ basic✅ advanced✅ advanced
Adaptive ML tuning per IP❌✅✅
Attack analytics & metrics❌✅✅
Attack mitigation reports❌✅✅
Attack mitigation flow logs❌✅✅
Azure Monitor alerts❌✅✅
WAF policy integration❌✅✅
DDoS Rapid Response (Microsoft experts)❌✅❌
Cost protection (service credit)❌✅✅
ScopeAll Azure (shared)Per VNet (plan)Per public IP
PricingFree~$2,944/month + per IP~$199/IP/month

Network Protection (the classic “Standard” tier) is applied at the VNet level via a DDoS Protection Plan — every public IP in all linked VNets is automatically covered.

IP Protection is a newer, per-IP option introduced for smaller deployments where you only need to protect a handful of public IPs without paying for a full plan.

What a DDoS Protection Plan Covers

A single DDoS Protection Plan can be linked to multiple VNets across multiple subscriptions in the same tenant. This is the right model for hub and spoke — one plan at the hub subscription level covers everything:

DDoS Protection Plan (resource group: rg-network-hub)
        ↓  linked to
Hub VNet          → VPN Gateway public IP protected
                  → Azure Firewall public IP protected
                  → Bastion public IP protected
Spoke 4 (DMZ)     → App Gateway public IP protected
                  → Load Balancer public IP protected

The first 100 public IPs are included in the plan price. Beyond 100, you pay per additional IP.

Monitoring and Alerting

During and after an attack, DDoS Protection surfaces detailed metrics in Azure Monitor:

MetricWhat it shows
Under DDoS attackBoolean — 1 if attack active on this IP
Inbound packets dropped DDoSPackets/sec being scrubbed
Inbound packets forwarded DDoSClean packets/sec passing through
Inbound bytes DDoSRaw attack volume in bytes/sec
Mitigation reasonSYN flood, UDP flood, etc.

Set an alert rule on Under DDoS attack = 1 to fire a notification to your security team or trigger a Logic App / n8n workflow the moment an attack begins.

When Should You Enable It?

Enable DDoS Protection Standard when any of these are true

Any public-facing production workload with real business impact if taken offline — an internet-facing Application Gateway, a VPN Gateway handling thousands of remote users, or a load balancer fronting a revenue-generating application — warrants the protection. The ~$3K/month cost is trivial compared to the revenue loss and incident response cost of a successful multi-hour DDoS attack.

You also need it when compliance frameworks require it. PCI-DSS, HIPAA, and ISO 27001 environments often require documented DDoS mitigation controls, and DDoS Protection Standard gives you the attack reports and flow logs needed to satisfy auditors.

The cost protection feature is a practical reason too — if an attack causes your Azure compute or bandwidth costs to spike (autoscaled VMs spun up to handle flood traffic, for example), Microsoft will credit those costs back when DDoS Protection was enabled.

You can skip it when

Dev/test environments, internal-only workloads with no public IPs, and resources entirely behind Azure Front Door or a third-party CDN that absorbs attacks upstream don’t need the plan — the Basic tier’s shared protection is sufficient, and the CDN/Front Door layer already absorbs volumetric attacks before they reach your origin.

In a Hub and Spoke Context

The recommended placement is one DDoS Protection Plan at the hub subscription, linked to the hub VNet and any spoke VNets that have public IPs (typically the DMZ spoke with App Gateway and WAF). Pair it with Azure Firewall for Layer 3/4 east-west filtering and Azure WAF on Application Gateway for Layer 7 protection, and you have defence-in-depth across all three attack categories.

Managing DNS Efficiently with Azure Private Resolver

techhadoop azure , , , ,

Azure DNS Private Resolver

Azure DNS Private Resolver is a fully managed, highly available DNS service that lets your spoke VNets and on-premises networks resolve Azure private DNS zones — without deploying and managing DNS virtual machines.

Before Private Resolver existed, enterprises had to run Windows Server DNS VMs in the hub to forward queries between on-premises and Azure. Private Resolver replaces that entirely with a managed service.

The Two Endpoints

DNS Private Resolver has two endpoint types, each deployed into a dedicated delegated subnet inside the hub VNet.

Inbound Endpoint

Receives DNS queries from outside Azure — from on-premises DNS servers or spoke VNets that point their DNS server setting directly at this IP.

  • Gets a static private IP from your hub VNet subnet (e.g. 10.0.5.4)
  • Reachable over VPN Gateway or ExpressRoute from on-premises
  • On-premises DNS servers forward specific zones (e.g. *.privatelink.blob.core.windows.net) to this IP
  • Requires a dedicated /28 subnet named however you like (e.g. snet-dns-inbound)

Outbound Endpoint

Forwards DNS queries from Azure to external resolvers — typically to on-premises DNS servers for resolving internal corp domains like *.contoso.local.

  • Also gets a private IP from a dedicated /28 subnet
  • Does not receive queries directly — works only through a Forwarding Ruleset
  • Requires a dedicated subnet separate from the inbound endpoint subnet

Forwarding Ruleset

A Forwarding Ruleset is a collection of conditional forwarding rules attached to the outbound endpoint. You then link the ruleset to spoke VNets so those spokes inherit the forwarding rules automatically.

Example ruleset rules

DomainForwarding targetUse
contoso.local.192.168.1.10:53 (on-prem DNS)Resolve internal corp names
corp.contoso.com.192.168.1.10:53Resolve corp public domain internally
prod.internal.10.3.2.5:53Resolve shared-services zone
. (wildcard)168.63.129.16:53All other queries → Azure public DNS

The wildcard . rule is the catch-all — any query that doesn’t match a specific rule falls through to Azure’s public DNS resolver.

How Spoke VNets Resolve Private DNS Zones

There are two patterns depending on whether you want centralised or per-VNet control.

Pattern 1 — Custom DNS server pointing to inbound endpoint (recommended)

Each spoke VNet sets its DNS server to the inbound endpoint’s private IP (10.0.5.4) instead of the default Azure DNS (168.63.129.16):

Spoke VM queries: myaccount.blob.core.windows.net
        ↓
Spoke VNet DNS setting → 10.0.5.4 (inbound endpoint)
        ↓
DNS Private Resolver checks private DNS zones
        ↓
Finds: myaccount.blob.core.windows.net → 10.1.8.4 (private endpoint IP)
        ↓
Returns private IP — traffic stays on private network

This is set at the VNet level in Azure portal or via ARM:

{
  "dhcpOptions": {
    "dnsServers": ["10.0.5.4"]
  }
}

Pattern 2 — Ruleset linked to spoke VNets

Link the hub’s forwarding ruleset directly to each spoke VNet. The spoke VNets keep the default Azure DNS (168.63.129.16) but inherit the conditional forwarding rules from the ruleset:

Spoke VM queries: server01.contoso.local
        ↓
Azure DNS (168.63.129.16) — checks linked ruleset
        ↓
Ruleset rule: contoso.local → forward to 192.168.1.10
        ↓
Outbound endpoint forwards to on-premises DNS
        ↓
On-premises DNS returns 192.168.10.45

Pattern 2 avoids changing the DNS server setting on every spoke and is easier to manage at scale — you just link new spokes to the existing ruleset.

Private DNS Zone Resolution Flow (Full Detail)

1. Developer VM in prod spoke queries:
   mydb.privatelink.database.windows.net
2. Query goes to 10.0.5.4 (inbound endpoint)
3. DNS Private Resolver checks:
   → Is there a forwarding rule for this domain? No
   → Is there a linked private DNS zone? Yes
     Zone: privatelink.database.windows.net
     Record: mydb → 10.1.9.6 (private endpoint NIC IP)
4. Returns: mydb.privatelink.database.windows.net = 10.1.9.6
5. VM connects to SQL on 10.1.9.6
   Traffic never leaves Azure backbone

Without DNS Private Resolver, the public DNS record for mydb.database.windows.net would resolve to the public IP, bypassing your private endpoint entirely.

Private DNS Zone Auto-Registration

When you create Azure PaaS resources with private endpoints, you link them to a private DNS zone. Common zones:

ServicePrivate DNS zone
Azure Blob Storageprivatelink.blob.core.windows.net
Azure SQL Databaseprivatelink.database.windows.net
Azure Key Vaultprivatelink.vaultcore.azure.net
Azure Container Registryprivatelink.azurecr.io
Azure Kubernetes Serviceprivatelink.{region}.azmk8s.io
Azure Monitorprivatelink.monitor.azure.com
Azure Service Busprivatelink.servicebus.windows.net

All these zones are linked to the hub VNet where DNS Private Resolver lives. Because all spokes resolve through the resolver, they automatically get the private IPs for these services.

Subnet Requirements

EndpointSubnet name (your choice)Min sizeDelegation
Inbounde.g. snet-dns-inbound/28 (16 IPs)Microsoft.Network/dnsResolvers
Outbounde.g. snet-dns-outbound/28 (16 IPs)Microsoft.Network/dnsResolvers

Both subnets must be in the hub VNet, must be separate from each other, and must not contain any other resources. The delegation is set automatically when you create the endpoint.

Before vs After Private Resolver

Before (DNS VMs)After (DNS Private Resolver)
Infrastructure2+ Windows DNS VMs in hubZero VMs — fully managed
High availabilityManual VM HA, availability setsBuilt-in, 99.99% SLA
MaintenancePatch, monitor, backup VMsNone
Conditional forwardingConfigured per-VMForwarding rulesets, linked to VNets
On-premises resolutionRequires VM reachabilityInbound endpoint IP, reachable over VPN/ER
CostVM compute + licencesPer-endpoint + per-query pricing

DNS Private Resolver is one of the clearest examples in Azure of a managed service eliminating operational overhead — the old pattern of DNS VMs in the hub was fragile, expensive, and easy to misconfigure.

Image Signing Guide with Tekton Chains on OCP

techhadoop OCP , , , ,

A complete guide to image signing with Tekton Chains on OCP — covering the concept, the setup, the pipeline integration, and verification.—

What Tekton Chains does

Tekton Chains works by reconciling the run of a task or a pipeline. Once the run is observed as completed, Tekton Chains takes a snapshot of the completed TaskRun/PipelineRun, and starts its core work in the order of: formatting (generate provenance JSON) → signing (sign the payload using the configured key) → uploading (upload the provenance and its signature to the configured storage).

It operates entirely automatically — you don’t modify your pipeline at all. Chains watches completed runs and signs in the background.

Step 1 — Chains is already installed on OCP

The Red Hat OpenShift Pipelines Operator installs Tekton Chains by default. You can configure Tekton Chains by modifying the TektonConfig custom resource; the Operator automatically applies the changes that you make.

# Verify Chains is running
oc get pods -n openshift-pipelines | grep chains
# tekton-chains-controller-xxx   Running

Step 2 — Generate a signing key pair

# Install cosign (if not already)
brew install cosign   # or download binary
# Generate key pair — stores private key as K8s secret automatically
cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
# This creates:
#   signing-secrets (K8s Secret) — holds cosign.key + cosign.password
#   cosign.pub (local file)      — distribute this for verification
# Extract public key for distribution/verification
oc get secret signing-secrets -n openshift-pipelines \
  -o jsonpath='{.data.cosign\.pub}' | base64 -d > cosign.pub

For production, use a KMS (AWS KMS, HashiCorp Vault, GCP KMS) instead of a file-based key:

# AWS KMS example
cosign generate-key-pair --kms awskms:///arn:aws:kms:ca-central-1:123456:key/abc-def

Step 3 — Configure Chains via TektonConfig

Cluster administrators can use Tekton Chains to sign and verify images and provenances by: creating an encrypted x509 key pair and saving it as a Kubernetes secret; setting up authentication for the OCI registry to store images, image signatures, and signed image attestations; and configuring Tekton Chains to generate and sign provenance.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  chain:
    # Format for TaskRun attestations
    artifacts.taskrun.format: "slsa/v1"          # SLSA v1.0 provenance
    artifacts.taskrun.storage: "oci"             # store in OCI registry
    # Format for PipelineRun attestations (recommended)
    artifacts.pipelinerun.format: "slsa/v1"
    artifacts.pipelinerun.storage: "oci"
    artifacts.pipelinerun.enable-deep-inspection: "true"  # inspect child TaskRuns
    # OCI image signature format
    artifacts.oci.format: "simplesigning"
    artifacts.oci.storage: "oci"
    # Transparency log (Sigstore Rekor)
    transparency.enabled: "true"
    transparency.url: "https://rekor.sigstore.dev"   # or your internal Rekor
    # Signing key reference
    signers.cosign.key: "k8s://openshift-pipelines/signing-secrets"

Apply via oc patch if you prefer:

oc patch tektonconfig config --type=merge -p='{
  "spec": {
    "chain": {
      "artifacts.pipelinerun.format": "slsa/v1",
      "artifacts.pipelinerun.storage": "oci",
      "artifacts.oci.format": "simplesigning",
      "artifacts.oci.storage": "oci",
      "transparency.enabled": "true"
    }
  }
}'

Step 4 — Type-hint your pipeline so Chains knows what to sign

Chains discovers what the output artifact is via type hints in Task results. Your build task must emit IMAGE_URL and IMAGE_DIGEST results:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: buildah-push
spec:
  params:
    - name: IMAGE
      type: string
  results:
    # Type hints — Chains reads these to find the artifact
    - name: IMAGE_URL
      description: The image URL
    - name: IMAGE_DIGEST
      description: The image digest (sha256)
  steps:
    - name: build-and-push
      image: registry.redhat.io/rhel8/buildah
      script: |
        buildah bud -t $(params.IMAGE) .
        buildah push $(params.IMAGE) \
          --digestfile /tmp/digest
        # Emit type hints for Chains
        echo -n "$(params.IMAGE)" | tee $(results.IMAGE_URL.path)
        cat /tmp/digest | tee $(results.IMAGE_DIGEST.path)

For pipeline-level provenance, also emit results at the Pipeline level:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-pipeline
spec:
  results:
    - name: IMAGE_URL
      value: $(tasks.build.results.IMAGE_URL)
    - name: IMAGE_DIGEST
      value: $(tasks.build.results.IMAGE_DIGEST)
  tasks:
    - name: build
      taskRef:
        name: buildah-push

Step 5 — What happens automatically after a run

Once your PipelineRun completes, Chains fires automatically. You can watch for the signed annotation:

# Watch for Chains to finish signing
oc get pipelinerun my-run -o json | jq '.metadata.annotations'
# {
#   "chains.tekton.dev/signed": "true",
#   "chains.tekton.dev/transparency": "https://rekor.sigstore.dev/api/v1/log/entries?logIndex=12345678"
# }
# What gets stored in the OCI registry alongside your image:
# myimage:sha256-abc123.sig           ← cosign image signature
# myimage:sha256-abc123.att           ← SLSA provenance attestation

Step 6 — Verify images before deployment

# Set your image reference (always use digest, not tag)
IMAGE="quay.io/my-org/my-app@sha256:abc123..."
# 1. Verify the image signature
cosign verify \
  --key cosign.pub \
  $IMAGE
# 2. Verify the SLSA provenance attestation
cosign verify-attestation \
  --key cosign.pub \
  --type slsaprovenance \
  $IMAGE | jq '.payload | @base64d | fromjson'
# 3. Check the Rekor transparency log entry
rekor-cli search --sha sha256:abc123...

The SLSA provenance JSON tells you exactly what built the image — the git commit, the pipeline name, each task step, and all input dependencies.

Step 7 — Enforce signatures at admission (policy gate)

Verification at deployment time is where this pays off. Use OCP’s built-in image policy or Kyverno/OPA to block unsigned images:

# Kyverno policy — block any image without a valid Chains signature
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-image-signature
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "quay.io/my-org/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      <your cosign.pub contents>
                      -----END PUBLIC KEY-----
          attestations:
            - predicateType: https://slsa.dev/provenance/v1
              conditions:
                - all:
                    - key: "{{ builder.id }}"
                      operator: Equals
                      value: "https://tekton.dev/chains/v2"

SLSA levels Tekton Chains achieves

SLSA levelRequirementChains status
Level 1Provenance existsAchieved — attestation generated automatically
Level 2Signed provenance, hosted buildAchieved — cosign signature + Rekor log entry
Level 3Hardened build platform, non-falsifiable provenanceAchieved with OCP’s isolated pod builds
Level 4Two-party review, hermetic buildsPartial — requires additional hermetic build config

The key benefit: by implementing provenance in CI/CD pipelines, you protect your supply chain from tampering and unauthorized access, streamline compliance with evolving industry and government regulations, and enhance visibility and trust throughout your software lifecycle.

Allow LDAP users to access the Kong Manager GUI in Kong Gateway

techhadoop Uncategorized , , , ,

To allow LDAP users to access the Kong Manager GUI in Kong Gateway Enterprise 3.4, you’ll need to integrate LDAP authentication via the Kong Enterprise Role-Based Access Control (RBAC) system.

Here’s how you can get it working step-by-step 👇

Step 1: Configure LDAP Authentication for Kong Manager

Edit your kong.conf or pass these as environment variables if you’re using a container setup.

admin_gui_auth = ldap-auth
admin_gui_auth_conf = {
  "ldap_host": "ldap.example.com",
  "ldap_port": 389,
  "ldap_base_dn": "dc=example,dc=com",
  "ldap_attribute": "uid",
  "ldap_bind_dn": "cn=admin,dc=example,dc=com",
  "ldap_password": "adminpassword",
  "start_tls": false,
  "verify_ldap_host": false
}

If you’re using LDAPS, set ldap_port = 636 and start_tls = false or configure accordingly.

Restart Kong after updating this config.

Step 2: Create an RBAC User Linked to the LDAP Username

Kong still needs an RBAC user that maps to the LDAP-authenticated identity.

curl -i -X POST http://localhost:8001/rbac/users \
  --data "name=jdoe" \
  --data "user_token=jdoe-admin-token"

The name here must match the LDAP uid or whatever attribute you configured with ldap_attribute.

Step 3: Assign a Role to the RBAC User

curl -i -X POST http://localhost:8001/rbac/users/jdoe/roles \
  --data "roles=read-only"  # Or "admin", "super-admin", etc.

Available roles: read-only, admin, super-admin, or your own custom roles.

Step 4: Log into Kong Manager with LDAP User

Go to your Kong Manager GUI:

https://<KONG_MANAGER_URL>:8445

Enter:

  • Username: jdoe (LDAP uid)
  • Password: LDAP user’s actual password (Kong will bind to LDAP and verify it)

Optional: Test LDAP Config from CLI

You can test the LDAP binding from Kong CLI:

curl -i -X POST http://localhost:8001/rbac/users \
  --data "name=testuser" \
  --data "user_token=test123"

Then try logging into Kong Manager with testuser using their LDAP password.

How to generate a ticket in MapR – HPE Ezmeral

techhadoop Uncategorized , , , ,

How to generate a ticket in MapR

To generate a MapR user ticket, you can use the maprlogin command. Here’s a step-by-step guide:

Steps to Generate a MapR User Ticket

  1. Open Terminal: Open your terminal window.
  2. Run the Command: Use the maprlogin password command to generate a user ticket. This command will prompt you for the user’s password1.

maprlogin password

For example:

maprlogin password [Password for user ‘yourusername’ at cluster ‘your.cluster.com’: ]

  1. Generate the Ticket: The command will generate a ticket file and store it in the /tmp directory by default. The ticket file will be named maprticket_<UID>.

Example

Let’s say you want to generate a ticket for the user juser on the cluster my.cluster.com:

maprlogin password [Password for user ‘juser’ at cluster ‘my.cluster.com’: ]

MapR credentials of user ‘juser’ for cluster ‘my.cluster.com’ are written to ‘/tmp/maprticket_1000’

Verify the Ticket

To verify the ticket, you can use the maprlogin print command:

maprlogin print

This command will display the ticket details, including the user, creation time, expiration time, and renewal information.

Renewing ticket

To renew a MapR user ticket, you can use the maprlogin command with the -renewal option. Here’s how you can do it:

Steps to Renew a MapR User Ticket

  1. Open Terminal: Open your terminal window.
  2. Generate a New Ticket: Use the maprlogin command with the -renewal option to renew the ticket. You’ll need to specify the duration for the renewed ticket1.

maprlogin password -renewal <duration>

Replace <duration> with the desired duration for the renewed ticket (e.g., 30:0:0 for 30 days).

Example

Let’s say you want to renew the ticket for 30 days:

maprlogin password -renewal 30:0:0

Verify the Renewed Ticket

To verify that the ticket has been renewed, you can use the maprlogin print command:

maprlogin print

This command will display the ticket details, including the new expiration date.

Managing Tickets

Managing MapR tickets involves creating, renewing, and revoking user tickets that are required for authentication and authorization in a MapR cluster. Here are the key aspects of ticket management:

1. Generating a Ticket

  • Create a User Ticket: Use the maprlogin command to generate a ticket:

maprlogin password

This will prompt you to enter the user’s password and generate a ticket file.

2. Viewing Ticket Information

  • Check Ticket Details: Use the maprlogin print command to display the current ticket details:

maprlogin print

This shows the user, creation time, expiration time, and other details of the ticket.

3. Renewing a Ticket

  • Renew the Ticket: If your ticket is about to expire, you can renew it using:
  •  

maprlogin password -renewal <duration>

Replace <duration> with the desired duration for the renewed ticket (e.g., 30:0:0 for 30 days).

4. Revoking a Ticket

  • Revoke a Ticket: To revoke a ticket, you can use the maprcli command:

maprcli session delete -type service -user <username>

Replace <username> with the name of the user whose ticket you want to revoke.

5. Managing Ticket Expiration

  • Set Ticket Lifetime: You can set the lifetime of a ticket using the maprcli config save command:

maprcli config save -values { “ticket.lifetime” : “24:0:0” }

This sets the default ticket lifetime to 24 hours.

6. Checking Ticket Validity

  • Validate Ticket: To check if a ticket is still valid, you can use the maprlogin command:

maprlogin info

This command provides information on the validity and expiration of the ticket.

Best Practices

  • Regular Renewal: Ensure tickets are renewed regularly to avoid authentication issues.
  • Monitor Expiration: Keep track of ticket expiration times and set reminders if necessary.
  • Secure Storage: Store ticket files securely and restrict access to authorized users only.
  • Use Service Tickets: For applications and services, use service tickets that have appropriate lifetimes and permissions.

By following these steps and best practices, you can effectively manage MapR user tickets and ensure smooth operation of your MapR cluster.

Securing an HPE Ezmeral Data Fabric

techhadoop Uncategorized , , , ,

Security

Securing an HPE Ezmeral Data Fabric (formerly MapR) Hadoop cluster involves implementing a multi-layered security strategy that covers authentication, authorization, encryption, and monitoring. Below is a comprehensive guide to securing your HPE Ezmeral Hadoop cluster:

1. Authentication

Implement strong authentication mechanisms to ensure that only authorized users and applications can access the cluster.

  • Kerberos Integration:
    • Use Kerberos for secure authentication of users and services.
    • Configure Kerberos key distribution centers (KDCs) and set up service principals for all Hadoop components.
  • LDAP/AD Integration:
    • Integrate the cluster with LDAP or Active Directory (AD) for centralized user authentication.
    • Use Pluggable Authentication Modules (PAM) to synchronize user credentials.
  • Token-based Authentication:
    • Enable token-based authentication for inter-service communication to enhance security and reduce Kerberos dependency.

2. Authorization

Implement role-based access control (RBAC) to manage user and application permissions.

  • Access Control Lists (ACLs):
    • Configure ACLs for Hadoop Distributed File System (HDFS), YARN, and other services.
    • Restrict access to sensitive data directories.
  • Apache Ranger Integration:
    • Use Apache Ranger for centralized authorization management.
    • Define fine-grained policies for HDFS, Hive, and other components.
  • Group-based Permissions:
    • Assign users to appropriate groups and define group-level permissions for ease of management.

3. Encryption

Protect data at rest and in transit to prevent unauthorized access.

  • Data-at-Rest Encryption:
    • Use dm-crypt/LUKS for disk-level encryption of storage volumes.
    • Enable HDFS Transparent Data Encryption (TDE) for encrypting data blocks.
  • Data-in-Transit Encryption:
    • Configure TLS/SSL for all inter-service communication.
    • Use certificates signed by a trusted certificate authority (CA).
  • Key Management:
    • Implement a secure key management system, such as HPE Ezmeral Data Fabric’s built-in key management service or an external solution like HashiCorp Vault.

4. Network Security

Restrict network access to the cluster and its services.

  • Firewall Rules:
    • Limit inbound and outbound traffic to required ports only.
    • Use network segmentation to isolate the Hadoop cluster.
  • Private Networking:
    • Deploy the cluster in a private network (e.g., VPC on AWS or Azure).
    • Use VPN or Direct Connect for secure remote access.
  • Gateway Nodes:
    • Restrict direct access to Hadoop cluster nodes by using gateway or edge nodes.

5. Auditing and Monitoring

Monitor cluster activity and audit logs to detect and respond to security incidents.

  • Log Management:
    • Enable and centralize audit logging for HDFS, YARN, Hive, and other components.
    • Use tools like Splunk, Elasticsearch, or Fluentd for log aggregation and analysis.
  • Intrusion Detection:
    • Deploy intrusion detection systems (IDS) or intrusion prevention systems (IPS) to monitor network traffic.
  • Real-time Alerts:
    • Set up alerts for anomalous activities using monitoring tools like Prometheus, Grafana, or Nagios.

6. Secure Cluster Configuration

Ensure that the cluster components are securely configured.

  • Hadoop Configuration Files:
    • Disable unnecessary services and ports.
    • Set secure defaults for core-site.xml, hdfs-site.xml, and yarn-site.xml.
  • Service Accounts:
    • Run Hadoop services under dedicated user accounts with minimal privileges.
  • Regular Updates:
    • Keep the Hadoop distribution and all dependencies updated with the latest security patches.

7. User Security Awareness

Educate users on secure practices.

  • Strong Passwords:
    • Enforce password complexity requirements and periodic password changes.
  • Access Reviews:
    • Conduct regular access reviews to ensure that only authorized users have access.
  • Security Training:
    • Provide security awareness training to users and administrators.

8. Backup and Disaster Recovery

Ensure the availability and integrity of your data.

  • Backup Policy:
    • Regularly back up metadata and critical data to secure storage.
  • Disaster Recovery:
    • Implement a disaster recovery plan with off-site replication.

9. Compliance

Ensure the cluster complies with industry standards and regulations.

  • Data Protection Regulations:
    • Adhere to GDPR, HIPAA, PCI DSS, or other relevant standards.
    • Implement data masking and anonymization where required.
  • Third-party Audits:
    • Conduct periodic security assessments and audits.

By following these practices, you can ensure a robust security posture for your HPE Ezmeral Hadoop cluster.

F5 – kong configuration

techhadoop Uncategorized , , , ,

Configure the F5 Load Balancer with VIP and SSL Certificate

  1. Create a Virtual Server (VIP):
    • Log in to your F5 management console.
    • Navigate to Local Traffic > Virtual Servers > Virtual Server List.
    • Click Create and configure the following:
      • Name: Give the VIP a meaningful name, like Kong_VIP.
      • Destination Address: Specify the IP address for the VIP.
      • Service Port: Set to 443 for HTTPS.
  2. Assign an SSL Certificate to the VIP:
    • Under the SSL Profile (Client) section, select Custom.
    • For Client SSL Profile, choose an existing SSL profile, or create a new one if needed:
      • Go to Local Traffic > Profiles > SSL > Client.
      • Click Create and provide a name, then upload the SSL certificate and key.
    • Assign this SSL profile to your VIP.
  3. Configure Load Balancing Method:
    • Under Load Balancing Method, choose a method that best fits your setup, such as Round Robin or Least Connections.
  4. Set Up Pool and Pool Members:
    • In the Pool section, create or select a pool to add your Kong instances as members:
      • Go to Local Traffic > Pools > Pool List, then Create a new pool.
      • Assign Kong instances as Pool Members using their internal IP addresses and ports (usually port 8000 for HTTP or 8443 for HTTPS if Kong is configured with SSL).
    • Make sure health monitors are set up for these pool members to detect when a Kong instance goes down.

Setup

Whether you need certificates on both the F5 load balancer and the Kong servers depends on how you plan to manage SSL/TLS termination and the level of encryption required for traffic between the F5 and Kong.

Here are two common setups:

1. SSL Termination on the F5 (Most Common)

  • Certificate Location: Only on the F5 load balancer.
  • How It Works: The F5 terminates the SSL connection with clients, decrypts the incoming HTTPS traffic, and forwards it to the Kong servers as plain HTTP traffic.
  • Benefits: Reduces the overhead on Kong servers because they don’t need to handle SSL encryption. It’s simpler to manage as only the F5 requires an SSL certificate.
  • Considerations: Traffic between the F5 and Kong servers is unencrypted, which is typically acceptable in private or secured networks (e.g., within a secure data center or VPC).

Configuration Steps:

  • Install and configure the SSL certificate only on the F5.
  • Set the F5 VIP to listen on HTTPS (port 443).
  • Configure Kong to listen on HTTP (port 8000 or a custom port).

This setup is generally sufficient if Kong instances and the F5 are within a trusted network.

2. End-to-End SSL (SSL Termination on Both F5 and Kong Servers)

  • Certificate Location: On both the F5 load balancer and the Kong servers.
  • How It Works: The F5 terminates the initial SSL connection from the client, but then re-encrypts the traffic before forwarding it to Kong. Kong servers also have SSL certificates, allowing them to decrypt this re-encrypted traffic.
  • Benefits: Ensures encrypted communication all the way from the client to the Kong servers, providing an extra layer of security.
  • Considerations: Requires SSL certificates on both F5 and Kong, and introduces some additional CPU overhead on Kong due to the need to decrypt/encrypt traffic.

Configuration Steps:

  • Install and configure an SSL certificate on the F5 for the VIP, and configure the VIP to listen on HTTPS.
  • Install an SSL certificate on each Kong server (these can be the same certificate as the F5 or separate ones).
  • Configure Kong to listen on HTTPS (port 8443 or another SSL-enabled port).
  • Configure the F5 to forward encrypted traffic to the Kong servers’ HTTPS port.

This approach is beneficial if security policies require end-to-end encryption, especially if the connection between the F5 and Kong instances crosses less secure network segments.

Summary

  • If you’re terminating SSL on the F5 only: A certificate is only required on the F5.
  • If you need end-to-end encryption: SSL certificates are required on both the F5 and each Kong server.

In most enterprise environments, SSL termination on the F5 is sufficient. However, for environments with stringent security requirements, end-to-end SSL provides additional security by ensuring all connections remain encrypted.

mTLS

  • Certificates:
    • The F5 load balancer needs server and client certificates and CA certificates to validate clients (client mTLS) and backend servers (backend mTLS).
    • Backend servers need server certificates and may require a CA certificate to verify the F5’s client certificate.
  • mTLS Setup:
    • For mTLS from the client to the F5, configure the Client SSL Profile on the F5.
    • For mTLS between the F5 and backend servers, configure the Server SSL Profile and set backend servers (like Kong) to require mTLS by validating the F5’s client certificate.

This setup provides mutual authentication between clients, the F5, and backend servers, ensuring secure, verified communication across all components in the chain.

do i need a certificate on both servers and F5 load balancer also how i integrate with mtls ?

For mTLS (mutual TLS) integration with an F5 load balancer and downstream servers like Kong or another backend, it is essential to determine where the certificates are needed and how to configure mTLS for mutual authentication between clients, the F5, and backend servers.

Certificates on Both the F5 Load Balancer and Backend Servers

  1. Certificates on the F5 Load Balancer:
    • The F5 acts as the entry point for client connections and needs a server certificate to handle HTTPS traffic.
    • If using mTLS, the F5 will also need a client certificate and a trusted certificate authority (CA) to validate incoming client certificates.
    • The F5 can be configured to terminate SSL and optionally re-encrypt traffic to backend servers.
  2. Certificates on Backend Servers:
    • For end-to-end encryption (where traffic from the F5 to backend servers remains encrypted), each backend server (e.g., Kong) also needs a server certificate.
    • If mutual TLS is required between the F5 and backend servers, the backend servers also need to verify the client (F5’s) certificate, so you’ll need to import the F5’s client certificate or a shared CA certificate on backend servers.

Configuring mTLS on F5 Load Balancer

Here’s how you can set up mTLS on an F5 load balancer to handle mutual authentication with clients and potentially with backend servers:

1. Configure mTLS Between Client and F5

  • Client SSL Profile:
    • Go to Local Traffic > Profiles > SSL > Client.
    • Create a Client SSL Profile for the VIP and enable Client Certificate Authentication by selecting Require under Client Certificate.
    • Import or reference a CA certificate that you trust to sign client certificates. This CA will validate client certificates.
  • Assign SSL Profile to VIP:
    • Attach this client SSL profile to the VIP handling client requests.
    • The F5 will now require clients to present a valid certificate from the specified CA to establish a secure connection.

2. mTLS Between F5 and Backend Servers (Optional)

If you want end-to-end mTLS (client to F5 and F5 to backend):

  • Server SSL Profile:
    • Go to Local Traffic > Profiles > SSL > Server.
    • Create a Server SSL Profile and enable the Authenticate option to require the backend server to present a valid certificate.
    • Specify a trusted CA certificate to validate the backend server’s certificate.
  • Assign Server SSL Profile to Pool:
    • Attach this server SSL profile to the backend pool so that the F5 will establish an mTLS connection when connecting to each backend server.

Backend Server Configuration (e.g., Kong)

If Kong is the backend server, configure Kong to:

  • Present a server certificate to the F5 for mutual authentication.
  • Verify client certificates if mTLS is required from F5 to Kong:
    • Set client_ssl = on and configure ssl_client_certificate to reference the CA certificate or client certificates you trust.

Example snippet for kong.conf:

client_ssl = on

ssl_cert = /path/to/server.crt

ssl_cert_key = /path/to/server.key

ssl_client_certificate = /path/to/ca.crt  # This will be used to verify F5’s client certificate

Summary

  • Certificates:
    • The F5 load balancer needs server and client certificates and CA certificates to validate clients (client mTLS) and backend servers (backend mTLS).
    • Backend servers need server certificates and may require a CA certificate to verify the F5’s client certificate.
  • mTLS Setup:
    • For mTLS from the client to the F5, configure the Client SSL Profile on the F5.
    • For mTLS between the F5 and backend servers, configure the Server SSL Profile and set backend servers (like Kong) to require mTLS by validating the F5’s client certificate.

This setup provides mutual authentication between clients, the F5, and backend servers, ensuring secure, verified communication across all components in the chain.

setup both SSL and mTLS

Yes, you can absolutely have a setup with both SSL termination and mTLS on the F5 load balancer. Here’s how the setup would work, allowing for both standard SSL connections (for regular HTTPS traffic) and mTLS (for additional security and mutual authentication) on the same VIP.

Mixed SSL and mTLS on F5

The configuration would involve:

  1. Standard SSL Termination for clients that only need secure (HTTPS) connections.
  2. mTLS configuration for clients requiring mutual authentication (client certificate verification).

Steps to Set Up SSL and mTLS on F5

1. Configure VIP for SSL Termination with Optional mTLS

  1. Create a Client SSL Profile for Standard SSL:
    • Go to Local Traffic > Profiles > SSL > Client.
    • Create a new Client SSL profile for the VIP.
    • Import and assign the server certificate and private key for the F5 load balancer, enabling standard SSL termination for incoming HTTPS requests.
    • Set Client Certificate to Ignore or Optional for this profile. This setting allows both clients that do not have a client certificate and clients with a certificate to connect securely.
  2. Create an Additional Client SSL Profile for mTLS:
    • Create a second Client SSL Profile specifically for mTLS.
    • Assign the F5’s server certificate and private key as before.
    • Set Client Certificate to Require and specify the CA certificate that will validate incoming client certificates.
    • In Configuration > Authentication, select Require or Request to mandate client certificate validation for mTLS connections.
  3. Attach Both SSL Profiles to the VIP:
    • Attach both the standard SSL profile and mTLS SSL profile to the same VIP.
    • The F5 will now support both types of SSL connections (standard and mTLS) for incoming traffic.

2. Backend SSL Configuration (Optional)

If you want end-to-end SSL or mTLS between the F5 and backend servers:

  1. Create a Server SSL Profile for Backend SSL:
    • Go to Local Traffic > Profiles > SSL > Server and create a new Server SSL Profile.
    • Specify a trusted CA certificate if backend servers require validation of the F5’s certificate for mTLS.
    • Attach this Server SSL Profile to the backend pool so the F5 will establish an encrypted connection to the backend servers.
    • For mutual TLS to backend servers, configure the backend servers (e.g., Kong) to validate the F5’s client certificate.

3. Test SSL and mTLS Connections

  1. SSL Connection:
    • Test a standard SSL connection by accessing the VIP without providing a client certificate.
    • The F5 should accept the connection securely without requiring a client certificate.
  2. mTLS Connection:
    • Test an mTLS connection by providing a valid client certificate signed by the trusted CA.
    • The F5 should validate the client certificate before establishing the connection.

Summary

  • SSL and mTLS Profiles: Attach both a standard SSL profile (with client certificate optional or ignored) and an mTLS SSL profile (with client certificate required) to the same VIP.
  • Optional Backend mTLS: Optionally, configure mTLS for connections from the F5 to backend servers if end-to-end mutual authentication is required.
  • Client Experience: Clients that support mTLS can authenticate with certificates, while clients without certificates can still connect over standard SSL.

This configuration allows the F5 to handle both SSL and mTLS connections on the same endpoint, supporting secure flexibility in handling a range of client needs and security requirements.

Common Issues and Resolutions

1. Certificate Verification Failed

If Kong logs errors like:

  • unable to get local issuer certificate
  • certificate verify failed

Cause

  • F5 is presenting a certificate that Kong cannot validate because the CA is not trusted or the certificate chain is incomplete.

Solution

  1. Verify F5 Certificate Chain:
    • Ensure F5 is presenting the full certificate chain, including intermediate and root certificates.
    • On F5, upload the intermediate and root certificates alongside the server certificate.

Steps in F5:

  1. Go to System → File Management → SSL Certificate List.
  2. Import the intermediate and root certificates if missing.
  3. Assign them to the SSL profile.
  4. Add the Root CA to Kong:
    • Export the root certificate (and intermediate certificate, if needed) from F5.
    • Add the CA to Kong’s trusted store:

curl -i -X POST http://<KONG_ADMIN_API&gt;:8001/ca_certificates \

  –data “cert=$(cat /path/to/root_ca.pem)”

  1. Enable Certificate Validation in Kong:
    • Ensure the tls_verify option is enabled for services connecting to F5:

curl -i -X PATCH http://<KONG_ADMIN_API&gt;:8001/services/<SERVICE_NAME_OR_ID> \

  –data “tls_verify=true”

2. SNI Mismatch

If Kong logs errors like:

  • SSL: certificate name does not match

Cause

  • The Server Name Indication (SNI) sent by Kong does not match the hostname in F5’s SSL certificate.

Solution

  1. Verify F5 SSL Certificate:
    • Ensure the certificate on F5 is issued for the hostname used by Kong.
    • Use a tool like openssl to check the F5 certificate:

openssl s_client -connect <F5_VIP>:443 -showcerts

  1. Set SNI in Kong:
    • Specify the correct SNI for the service in Kong:

bash

Copy code

curl -i -X PATCH http://<KONG_ADMIN_API&gt;:8001/services/<SERVICE_NAME_OR_ID> \

  –data “tls_verify=true” \

  –data “tls_verify_depth=2” \

  –data “sni=<F5_HOSTNAME>”

3. Mutual TLS (mTLS) Configuration

If using mTLS, errors may include:

  • SSL handshake failed
  • no client certificate presented

Cause

  • Kong is not presenting a client certificate, or F5 is not configured to validate the client certificate.

Solution

  1. Upload Client Certificate to Kong:
    • Add the client certificate and private key to Kong:

bash

curl -i -X POST http://<KONG_ADMIN_API&gt;:8001/certificates \

  –data “cert=$(cat /path/to/client_certificate.pem)” \

  –data “key=$(cat /path/to/client_key.pem)”

  1. Associate the Certificate with the Service:
    • Attach the certificate to the service connecting to F5:

bash

Copy code

curl -i -X PATCH http://<KONG_ADMIN_API&gt;:8001/services/<SERVICE_NAME_OR_ID> \

  –data “client_certificate=<CERTIFICATE_ID>”

  1. Enable Client Certificate Validation on F5:
    • On F5, enable client certificate authentication in the SSL profile:
      • Go to Local Traffic → SSL Profiles → Edit the profile.
      • Enable Require Client Certificate.
      • Upload the CA certificate that issued the client certificate.

4. Protocol or Cipher Mismatch

Errors like:

  • SSL routines:ssl_choose_client_version:unsupported protocol
  • ssl_cipher_list failure

Cause

  • Mismatch in SSL protocols or ciphers supported by F5 and Kong.

Solution

  1. Check SSL Protocols and Ciphers on F5:
    • Ensure F5 supports the protocols (e.g., TLS 1.2/1.3) and ciphers used by Kong.
    • Modify the F5 SSL profile to include compatible protocols and ciphers.
  2. Set Cipher Suites in Kong:
    • Update Kong’s nginx_kong.conf to include compatible ciphers:

nginx

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_protocols TLSv1.2 TLSv1.3;

  1. Restart Kong after the update.

5. Untrusted Self-Signed Certificate

If F5 uses a self-signed certificate, Kong cannot validate it by default.

Solution

  1. Export the self-signed certificate from F5.
  2. Add the certificate to Kong’s trusted CA store:

bash

Copy code

curl -i -X POST http://<KONG_ADMIN_API&gt;:8001/ca_certificates \

  –data “cert=$(cat /path/to/self_signed_certificate.pem)”

Best Practices

  • Use Valid Certificates:
    • Always use certificates from trusted Certificate Authorities (CAs) for production systems.
  • Enable Logging:
    • Monitor logs in Kong and F5 to troubleshoot SSL/TLS issues.
  • Regular Certificate Rotation:
    • Ensure certificates are renewed and updated before expiry.
  • Secure Configuration:
    • Use modern TLS protocols (e.g., TLS 1.2/1.3) and strong cipher suites.

By addressing these common issues, you can ensure smooth integration between F5 and Kong Gateway with robust SSL/TLS security. Let me know if you need detailed help with any specific step!

Common Issues and Resolutions

1. Certificate Verification Failed

If Kong logs errors like:

  • unable to get local issuer certificate
  • certificate verify failed

Cause

  • F5 is presenting a certificate that Kong cannot validate because the CA is not trusted or the certificate chain is incomplete.

Solution

  1. Verify F5 Certificate Chain:
    • Ensure F5 is presenting the full certificate chain, including intermediate and root certificates.
    • On F5, upload the intermediate and root certificates alongside the server certificate.

Steps in F5:

  1. Go to System → File Management → SSL Certificate List.
  2. Import the intermediate and root certificates if missing.
  3. Assign them to the SSL profile.
  4. Add the Root CA to Kong:
    • Export the root certificate (and intermediate certificate, if needed) from F5.
    • Add the CA to Kong’s trusted store:

curl -i -X POST http://<KONG_ADMIN_API&gt;:8001/ca_certificates \

  –data “cert=$(cat /path/to/root_ca.pem)”

  1. Enable Certificate Validation in Kong:
    • Ensure the tls_verify option is enabled for services connecting to F5:

curl -i -X PATCH http://<KONG_ADMIN_API&gt;:8001/services/<SERVICE_NAME_OR_ID> \

  –data “tls_verify=true”

2. SNI Mismatch

If Kong logs errors like:

  • SSL: certificate name does not match

Cause

  • The Server Name Indication (SNI) sent by Kong does not match the hostname in F5’s SSL certificate.

Solution

  1. Verify F5 SSL Certificate:
    • Ensure the certificate on F5 is issued for the hostname used by Kong.
    • Use a tool like openssl to check the F5 certificate:

openssl s_client -connect <F5_VIP>:443 -showcerts

  1. Set SNI in Kong:
    • Specify the correct SNI for the service in Kong:

curl -i -X PATCH http://<KONG_ADMIN_API&gt;:8001/services/<SERVICE_NAME_OR_ID> \

  –data “tls_verify=true” \

  –data “tls_verify_depth=2” \

  –data “sni=<F5_HOSTNAME>”

3. Mutual TLS (mTLS) Configuration

If using mTLS, errors may include:

  • SSL handshake failed
  • no client certificate presented

Cause

  • Kong is not presenting a client certificate, or F5 is not configured to validate the client certificate.

Solution

  1. Upload Client Certificate to Kong:
    • Add the client certificate and private key to Kong:

curl -i -X POST http://<KONG_ADMIN_API&gt;:8001/certificates \

  –data “cert=$(cat /path/to/client_certificate.pem)” \

  –data “key=$(cat /path/to/client_key.pem)”

  1. Associate the Certificate with the Service:
    • Attach the certificate to the service connecting to F5:

curl -i -X PATCH http://<KONG_ADMIN_API&gt;:8001/services/<SERVICE_NAME_OR_ID> \

  –data “client_certificate=<CERTIFICATE_ID>”

  1. Enable Client Certificate Validation on F5:
    • On F5, enable client certificate authentication in the SSL profile:
      • Go to Local Traffic → SSL Profiles → Edit the profile.
      • Enable Require Client Certificate.
      • Upload the CA certificate that issued the client certificate.

4. Protocol or Cipher Mismatch

Errors like:

  • SSL routines:ssl_choose_client_version:unsupported protocol
  • ssl_cipher_list failure

Cause

  • Mismatch in SSL protocols or ciphers supported by F5 and Kong.

Solution

  1. Check SSL Protocols and Ciphers on F5:
    • Ensure F5 supports the protocols (e.g., TLS 1.2/1.3) and ciphers used by Kong.
    • Modify the F5 SSL profile to include compatible protocols and ciphers.
  2. Set Cipher Suites in Kong:
    • Update Kong’s nginx_kong.conf to include compatible ciphers:

nginx

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_protocols TLSv1.2 TLSv1.3;

  1. Restart Kong after the update.

5. Untrusted Self-Signed Certificate

If F5 uses a self-signed certificate, Kong cannot validate it by default.

Solution

  1. Export the self-signed certificate from F5.
  2. Add the certificate to Kong’s trusted CA store:

curl -i -X POST http://<KONG_ADMIN_API&gt;:8001/ca_certificates \

  –data “cert=$(cat /path/to/self_signed_certificate.pem)”

Best Practices

  • Use Valid Certificates:
    • Always use certificates from trusted Certificate Authorities (CAs) for production systems.
  • Enable Logging:
    • Monitor logs in Kong and F5 to troubleshoot SSL/TLS issues.
  • Regular Certificate Rotation:
    • Ensure certificates are renewed and updated before expiry.
  • Secure Configuration:
    • Use modern TLS protocols (e.g., TLS 1.2/1.3) and strong cipher suites.

By addressing these common issues, you can ensure smooth integration between F5 and Kong Gateway with robust SSL/TLS security. Let me know if you need detailed help with any specific step!

Kong – Ldap setting

techhadoop Uncategorized , , , ,

For Kong’s Admin API to have visibility into LDAP users and roles, the following steps ensure LDAP users are recognized and mapped to roles in Kong’s RBAC system. Here’s an overview of how it works and how to set it up:

1. Enable LDAP Authentication on the Admin API

  • Configure Kong to authenticate users from an LDAP server by setting up the ldap-auth plugin on the Admin API. This allows the Admin API to recognize LDAP credentials and authenticate users.
  • This configuration is typically done in kong.conf or using environment variables when launching Kong:

export KONG_ADMIN_LISTEN=”0.0.0.0:8001″

export KONG_LDAP_HOST=”ldap-server.example.com”

export KONG_LDAP_PORT=389

export KONG_LDAP_BASE_DN=”ou=users,dc=example,dc=com”

export KONG_LDAP_BIND_DN=”cn=admin,dc=example,dc=com”

export KONG_LDAP_BIND_PASSWORD=”admin_password”

2. Configure LDAP Bindings for Users in RBAC

  • After LDAP is enabled, Kong must map LDAP users to RBAC roles. This can be done by associating Kong roles with the LDAP user groups or specific LDAP users through RBAC settings.
  • You can create roles and assign permissions to them in Kong’s RBAC configuration by using Admin API requests. For example:

# Create a custom role (if you don’t want to use kong-admin)

curl -i -X POST http://localhost:8001/rbac/roles \

     –data “name=admin-role”

# Assign permissions to the role

curl -i -X POST http://localhost:8001/rbac/roles/admin-role/endpoints \

     –data “workspace=default” \

     –data “endpoint=/services” \

     –data “actions=read,update”

3. Map LDAP Users to Roles

  • Once the roles are set up, map LDAP users to the created roles. You can do this by adding RBAC permissions based on LDAP username:

# Assign the LDAP user to the role

curl -i -X POST http://localhost:8001/rbac/users \

     –data “username=<ldap-username>” \

     –data “custom_id=<unique-ldap-id>” \

     –data “roles=admin-role”

  • Here, <ldap-username> is the LDAP user, and <unique-ldap-id> is the identifier used in LDAP (e.g., uid=…).

4. Authenticate via LDAP User to Access Admin API

  • After assigning the role to the LDAP user, authenticate as the LDAP user using the Admin API. Kong will check the LDAP server for credentials and match the user to the associated RBAC role.
  • Once authenticated, LDAP users with RBAC roles are granted access based on their assigned permissions in Kong.

5. Verify Configuration

  • Test that your LDAP users can access Kong’s Admin API endpoints according to their role permissions by using curl or another HTTP client, as previously described.

com.pingidentity.pf.datastore an error occured while testing the connection Error PKIX path building failed

techhadoop Uncategorized , , , ,

The error you’re encountering, PKIX path building failed, is related to SSL certificate validation in PingIdentity while attempting to establish a connection. Specifically, it indicates that the system could not verify the certificate path back to a trusted root certificate authority (CA). This is a common issue when a server certificate is either self-signed or not recognized by the trust store.

Here’s a breakdown of the error:

  1. PKIX path building failed: This means that Java’s SSL/TLS system could not build a valid certificate chain back to a trusted root certificate authority.
  2. SunCertPathBuilderException: unable to find valid certification path to requested target: This suggests that the certificate presented by the remote system is not trusted by the client making the request. The client’s trust store (Java keystore) does not have the necessary CA certificates to validate the server certificate.

Causes:

  • Self-signed certificate: If the server you’re trying to connect to uses a self-signed certificate, it won’t be trusted automatically.
  • Untrusted CA: The certificate is signed by a CA that’s not included in the default trust store of the Java Virtual Machine (JVM).
  • Missing intermediate certificates: The certificate chain might be incomplete, missing intermediate certificates between the server’s certificate and the trusted root.
  • Expired or revoked certificates: The server certificate could be expired or revoked, leading to validation failure.

Solutions:

1. Import the Server’s Certificate to the Java Truststore

You need to import the server’s certificate (or the intermediate CA certificates) into the Java trust store to ensure it’s recognized as a trusted certificate.

Steps:

  • Obtain the server certificate:

openssl s_client -connect <server-host>:<port> -showcerts

This will return the server’s SSL certificate chain. Copy the relevant certificate (in PEM format).

  • Save the certificate as server.crt.
  • Import the certificate into the Java trust store:

keytool -import -alias <alias_name> -keystore <path_to_java_home>/lib/security/cacerts -file server.crt

The default password for the trust store is usually changeit, but this can vary.

  • Restart your PingFederate server or application to ensure the new trust store is loaded.

2. Use a Valid SSL Certificate

  • If the server is using a self-signed certificate, consider replacing it with one signed by a trusted public CA (e.g., Let’s Encrypt, GlobalSign, etc.).
  • Ensure the entire certificate chain, including intermediate certificates, is properly configured on the server.

3. Disable SSL Validation (Not Recommended in Production)

You can temporarily disable SSL validation to allow connections without certificate verification. This is usually done in testing environments or when working with self-signed certificates.

Example: In Java, you can disable SSL certificate validation by setting a custom trust manager, but this approach is not secure and should be avoided in production:

import javax.net.ssl.*;

import java.security.SecureRandom;

import java.security.cert.X509Certificate;

TrustManager[] trustAllCerts = new TrustManager[]{

    new X509TrustManager() {

        public X509Certificate[] getAcceptedIssuers() {

            return null;

        }

        public void checkClientTrusted(X509Certificate[] certs, String authType) {}

        public void checkServerTrusted(X509Certificate[] certs, String authType) {}

    }

};

SSLContext sc = SSLContext.getInstance(“SSL”);

sc.init(null, trustAllCerts, new SecureRandom());

HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

This solution is not recommended for production environments.

4. Verify the Server Certificate

Ensure that the certificate on the server is not expired, properly configured, and includes all intermediate certificates. You can use tools like:

openssl s_client -connect <server-host>:<port> -showcerts

5. Update the JVM Truststore (if outdated)

If you are using an old version of Java, the default trust store may not include modern root CAs. You can update your JVM or manually update the CA certificates:

  • Download a fresh version of the cacerts file from the latest JVM or a trusted source.
  • Replace your current cacerts file (located in JAVA_HOME/lib/security) with the new one.

6. Proxy Configuration

If you’re using a proxy, make sure the proxy server has the necessary CA certificates and that PingFederate is properly configured to connect through the proxy.

Conclusion

To resolve the PKIX path building failed error, you will likely need to add the server certificate (or its CA) to your Java trust store. Ensure the server’s certificate chain is correctly configured and, if using self-signed certificates, import them into the trust store. Avoid disabling SSL validation in production environments due to security risks.