Month: June 2025

kong token expiration

techhadoop

If a token is issued with a 20-minute expiration time, it remains valid until it expires, regardless of whether a new token is issued afterward.

So:

  • Token A is issued at 14:00 → expires at 14:20.
  • Token B is issued at 14:05 → expires at 14:25.

Token A is still valid until 14:20, even though Token B was generated later.

Exceptions:

Some systems revoke old tokens when a new one is issued. This depends on the implementation:

  • Stateless tokens (e.g., JWT): Typically not revoked unless explicitly blacklisted or the signing key is rotated.
  • Stateful tokens (e.g., stored in a DB): The server might mark previous tokens as invalid upon issuing a new one.

To summarize:

Yes, the first token is still valid unless your system has explicit revocation logic

Kong error

techhadoop , , ,

The error:

no credentials found for given iss

in the Kong OIDC plugin means:

Kong received a token or request with an issuer (iss) claim, but it cannot find a matching configuration for that issuer.

🔍 Why This Happens

This usually occurs in one of these scenarios:

1. Missing or Incorrect config.issuer in the OIDC plugin

  • You did not set the exact issuer URL from Ping Identity in the plugin config.
  • Or you set it, but it’s spelled or formatted differently than what’s in the JWT’s iss claim.

Example:
If the token contains:

"iss": "https://auth.pingone.com/12345/as"

Then your OIDC plugin must be configured with:

config.issuer=https://auth.pingone.com/12345/as

2. Wrong Discovery Document

Kong uses the issuer to retrieve:

<issuer>/.well-known/openid-configuration

If the URL is incorrect or inaccessible, it can’t discover metadata and fails.

3. Token Issuer Doesn’t Match Plugin Config

  • You’re sending a JWT token manually (e.g., in Authorization: Bearer) and it’s not issued by the issuer you configured.
  • Kong expects the iss claim to match the config.issuer.

✅ Fix Steps

Step 1: Extract the Token’s Issuer

Run:

jwt decode <your-token>

Or paste the JWT into jwt.io and check the iss field.

Step 2: Update Plugin Config

Ensure the OIDC plugin config matches the exact iss value:

curl -X PATCH http://localhost:8001/plugins/<plugin-id> \
  --data "config.issuer=https://auth.pingone.com/12345/as"

Or if creating fresh:

curl -X POST http://localhost:8001/services/my-service/plugins \
  --data "name=openid-connect" \
  --data "config.issuer=https://auth.pingone.com/12345/as" \
  ...

🧪 Test Again

Once updated:

  1. Clear browser session or test in Postman
  2. Trigger the login flow again
  3. Ensure Kong receives a token from Ping with matching iss

Would you like help decoding the token or verifying your current plugin setup? You can paste the token header (without the signature) and I’ll check it.

Splunk

techhadoop

https://splunkbase.splunk.com/app/2757

he size of an API response can vary depending on several factors like the data being returned, server and client limits, and performance considerations. Here’s a breakdown of key aspects:

🔹 Typical Size Limits

  • REST APIs (JSON):
    • Common practical limits: 1–10 MB
    • Best practice: Keep responses under 1 MB for speed and reliability
  • GraphQL APIs:
    • Can return large nested objects, but pagination and limits are recommended
    • Many GraphQL servers default to 1 MB–5 MB limits
  • gRPC / Protobuf APIs:
    • Binary and more compact
    • Common limit: 4 MB (can be increased with config)

🔹 Platform & Framework Default Limits

Platform/FrameworkDefault Max Response Size
AWS API Gateway10 MB
Azure API Management100 MB (but gzip recommended)
Google Cloud Endpoints~32 MB
Node.js (Express)Unlimited, but memory-bound
Nginx reverse proxy1 MB (can be tuned with client_max_body_size)

🔹 Practical Guidelines

  • Use pagination for large datasets (e.g., limit=100&offset=0)
  • Enable compression (e.g., Gzip or Brotli) to reduce response size
  • Stream data (if large file or binary) rather than returning in a single response
  • Split large responses across multiple endpoints if needed

🔹 API Response Size Debugging

You can check actual size using tools like:

bashCopyEditcurl -s -w "%{size_download}\n" -o /dev/null https://api.example.com/data

Let me know your use case — REST, GraphQL, or gRPC — and I can give optimized recommendations.

MapR cluster

techhadoop
NodeCLDBZooKeeperRMHistoryServerNodeManagerFileserverMetrics
1✅✅✅✅✅
2✅✅✅✅✅
3✅✅✅✅✅
4✅✅✅✅✅
5✅✅✅
6✅✅✅
7✅✅✅
8✅✅✅
9✅✅✅
10✅✅✅
11✅✅✅
12✅✅✅

MapR Metrics Overview

🧩 Built-In Components

  • mapr-metrics: Core service that collects and stores metrics data
  • mapr-metrics-collector: Gathers performance metrics and feeds them into MapR Monitoring DB
  • mapr-metrics-role: Enables metrics roles on all nodes

Install these packages on each node (especially CLDB and RM nodes):

bashCopyEdityum install -y mapr-metrics mapr-metrics-collector

KONG – JWT plugins

techhadoop

For JWT plugins in Kong, client certificates are not typically required as part of the JWT validation process. However, let’s clarify based on potential misunderstandings:

✅ JWT Plugin Basics (No client certs needed)

  • JWT authentication in Kong works by verifying the JWT signature using either a shared secret (HS256) or a public key (RS256/ES256).
  • Kong does not require client certificates unless you are adding mutual TLS (mTLS) as an extra layer.

🔐 When Client Certificates Are Required

If you’re also enabling mTLS authentication using plugins like mtls-auth, or using Kong in a setup where TLS client auth is enforced at the proxy level, then:

  • Yes, you will typically use different client certificates per environment (dev/uat/prod) for security isolation and credential scoping.
  • This ensures:
    • Compromise in dev doesn’t impact prod.
    • You can rotate/test certs independently.

💡 Best Practice (if mTLS is involved)

EnvironmentClient CertNotes
Devclient-dev.crtLower trust level, used for testing
UATclient-uat.crtFor staging/pre-prod
Prodclient-prod.crtStrict security, strong validation policies

🎯 Summary

  • 🔸 For JWT plugin alone: No client certs are needed.
  • 🔸 If you combine with mTLS: Yes, use separate client certs per environment.
  • 🔒 Always store keys securely and rotate them periodically.

Kong troubleshooting

techhadoop , , , ,

A 502 Bad Gateway error in your setup:

Client → LB → KONG → LB → Server

means that Kong Gateway cannot successfully connect to the upstream server behind the second load balancer. Here’s how to troubleshoot and resolve it step by step:

🔁 Understanding the Flow

  1. Client hits the first LB (e.g., AWS ELB, NGINX).
  2. That LB forwards traffic to Kong Gateway.
  3. Kong receives the request and proxies it to a second LB.
  4. That LB routes to your actual upstream service.

🛠️ Troubleshooting Checklist

✅ 1. Check Upstream URL in Kong

  • Run: curl -s http://<KONG_ADMIN>:8001/services/<service-name>
  • Ensure the upstream URL (url or host) points to a valid, resolvable address (DNS or IP) and correct port.

Example:

{
  "host": "internal-lb.yourdomain.local",
  "port": 8080,
  "protocol": "http"
}

✅ 2. Test Kong’s Network Reachability

From the Kong container or host:

curl -v http://internal-lb.yourdomain.local:8080/

If this fails:

  • DNS resolution might be broken
  • Port might be blocked
  • LB might not route correctly

✅ 3. Enable Debug Logs in Kong

In kong.conf or via environment variable:

log_level = debug

Then check:

tail -f /usr/local/kong/logs/error.log

Look for messages like:

  • upstream timed out
  • could not resolve host
  • connection refused

✅ 4. Check Health of Second LB and Backend

  • Ensure second LB is up
  • Verify backend servers are healthy and accepting connections
  • Check if Kong’s IP is allowed (firewall or security group)

✅ 5. Check Kong Route & Service Configuration

Validate route is defined correctly:

curl -s http://<KONG_ADMIN>:8001/routes

Make sure paths, hosts, or methods match the request.

🧪 Example Kong Service & Route Setup

# Service pointing to internal load balancer
curl -i -X POST http://localhost:8001/services \
  --data name=upstream-service \
  --data url=http://internal-lb.yourdomain.local:8080

# Route for the service
curl -i -X POST http://localhost:8001/services/upstream-service/routes \
  --data paths[]=/api

🚫 Common Causes of 502 with LB Behind Kong

ProblemSolution
DNS resolution failureUse IP or fix /etc/resolv.conf or CoreDNS
Port not exposed or wrongConfirm port with nc or curl
Second LB not forwarding correctlyCheck LB target groups and health checks
Kong plugins (e.g., OIDC, rate-limit) errorDisable plugins temporarily to isolate
HTTP vs HTTPS mismatchEnsure protocol matches (http vs https)
Timeout too shortIncrease proxy_read_timeout or similar

✅ Final Tips

  • Try curl directly from Kong to the backend server.
  • Use Kong’s health check endpoint if you’re using upstream targets: curl http://localhost:8001/upstreams/<name>/health

If you share:

  • the exact curl call to Kong
  • the relevant Kong service/route config
  • error.log content from Kong

The error message “upstream prematurely closed connection while reading response header from upstream” in Kong Gateway indicates that Kong attempted to read the response headers from the upstream service, but the connection was closed unexpectedly before the headers were fully received. This typically results in a 502 Bad Gateway error.

Common Causes

  1. Upstream Service Crashes or Terminates Connection Early:
    • The upstream application may crash, encounter an error, or intentionally close the connection before sending a complete response.
  2. Timeouts:
    • The upstream service takes too long to respond, exceeding Kong’s configured timeouts.
  3. Keepalive Connection Issues:
    • Persistent connections (keepalive) between Kong and the upstream service may be closed unexpectedly by the upstream, leading to this error.
  4. Protocol Mismatch:
    • Kong expects a certain protocol (e.g., HTTP/1.1), but the upstream service responds differently or uses an incompatible protocol.
  5. Large Response Headers:
    • The upstream service sends headers that exceed Kong’s buffer sizes, causing the connection to be closed prematurely.

es, a mismatch between the protocol specified in Kong’s service configuration and the actual protocol used by the upstream service can lead to the error:

“upstream prematurely closed connection while reading response header from upstream”

This typically occurs when Kong attempts to communicate with an upstream service over HTTP, but the upstream expects HTTPS, or vice versa.

🔍 Understanding the Issue

When Kong is configured to connect to an upstream service, it uses the protocol specified in the service’s configuration. If the upstream service expects HTTPS connections and Kong is configured to use HTTP, the SSL/TLS handshake will fail, leading to the connection being closed prematurely.

Yes, a mismatch between the protocol specified in Kong’s service configuration and the actual protocol used by the upstream service can lead to the error:

“upstream prematurely closed connection while reading response header from upstream”

This typically occurs when Kong attempts to communicate with an upstream service over HTTP, but the upstream expects HTTPS, or vice versa.

🔍 Understanding the Issue

When Kong is configured to connect to an upstream service, it uses the protocol specified in the service’s configuration. If the upstream service expects HTTPS connections and Kong is configured to use HTTP, the SSL/TLS handshake will fail, leading to the connection being closed prematurely.

For example, if your upstream service is accessible at https://api.example.com, but Kong is configured with:

bashCopyEditcurl -i -X POST http://localhost:8001/services \
  --data name=example-service \
  --data url=http://api.example.com

Kong will attempt to connect over HTTP, resulting in a failed connection.

✅ Solution

Ensure that the protocol in Kong’s service configuration matches the protocol expected by the upstream service.

If the upstream service requires HTTPS, configure the service in Kong accordingly:

bashCopyEditcurl -i -X POST http://localhost:8001/services \
  --data name=example-service \
  --data url=https://api.example.com

This ensures that Kong establishes a secure connection using HTTPS, aligning with the upstream service’s expectations.