Hi @devpc, @Terry_McDonald1, @mohammed_raihan,
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
