Hi @pietrocelan, @Terry_McDonald1, @Community Alums,

I faced this exact same issue when setting up Kubernetes discovery for GKE and AWS EKS clusters! The

---

### STEP 4: Verify and Re-run Discovery

1. Wait 2-3 minutes for MID Server to fully restart
2. Navigate to: `Discovery > Discovery Schedules`
3. Open your Kubernetes discovery schedule
4. Click **Discover Now**
5. Monitor: `Discovery > Discovery Log` and `ECC Queue`

The SSL certificate error should now be resolved!

---

## ADDITIONAL TROUBLESHOOTING TIPS

### For AWS EKS Clusters:

If you're still seeing credential errors for EKS (as mentioned by @Pugedo), verify:

1. **IAM Role/Service Account** has correct permissions:
```json
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}]
}
```

2. **AWS Credentials** in ServiceNow are correctly configured with:
- Access Key ID
- Secret Access Key
- Proper IAM permissions

3. **Token Generation** - EKS uses temporary tokens. Make sure your MID Server can generate them.

---

### For GKE Clusters:

1. **Bearer Token** must have correct RBAC permissions:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: servicenow-discovery
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["get", "list"]
```

2. **Public IP Access** - Ensure your MID Server can reach the GKE cluster's public endpoint

3. **Firewall Rules** - Check GCP firewall allows MID Server IP

---

## VERIFICATION STEPS

After importing the certificate and restarting, you can verify the SSL connection:

**Windows PowerShell:**
```powershell
$url = "https://your-k8s-endpoint:443"
try {
$response = Invoke-WebRequest -Uri $url -Method Get -Headers @{Authorization="Bearer YOUR_TOKEN"}
Write-Host "SSL Connection Successful!"
} catch {
Write-Host "Error: $_"
}
```

**Linux:**
bash
curl -k https://your-k8s-endpoint:443/api/v1/namespaces \
-H "Authorization: Bearer YOUR_TOKEN"

## COMMON PITFALLS TO AVOID

1. ❌ **Don't use `mid.ssl.bootstrap.trust_mode=allow_all`** - This bypasses all SSL validation (insecure for production)
2. ❌ **Wrong Java keystore** - Make sure you're importing to the MID Server's JRE keystore, not system Java
3. ❌ **Forgetting to restart** - Certificate import requires MID Server restart to take effect
4. ❌ **Expired tokens** - Bearer tokens for K8s typically expire in 24-48 hours

---

## RESOURCES

I've created a detailed video tutorial covering this exact scenario:

🎥 **Kubernetes Discovery with ServiceNow - Complete Setup Guide**
Watch here: https://www.youtube.com/watch?v=8FaF_gb4zWY

📖 **Written Guide on ServiceNow Community:**
https://www.servicenow.com/community/itom-articles/kubernetes-discovery-with-servicenow-complete-set...

The video includes:
- Complete GKE cluster setup
- Bearer token creation
- SSL certificate configuration (19:00 mark)
- Step-by-step ServiceNow configuration
- Live troubleshooting demonstration

---

Hope this helps! Let me know if you're still facing issues after following these steps. Happy to help troubleshoot further!

---

If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'** and **'Accept it as a Solution'**? This will help other community members who might have the same question find the answer more easily.

Thank you for your consideration.

Selva Arun

#Kubernetes #Discovery #ITOM #Troubleshooting