Azure Kubernetes and SSL Cert Error after fresh deployment

StefanMiesem

Hello,

I tried to deploy the scim bridge in Azure Kubernetes. I followed the guide here https://support.1password.com/scim-deploy-azure/. DNS A record is pointing to the loadbalancer ip. But when I try to connect to the dns name I get an error that seems to me like there is no certificate deployed:
ERR_SSL_PROTOCOL_ERROR

http is not working to because the deployment redirects to https.

Where can I start to debug this issue? As far as I understood, I can not simply redeploy the kubernetes cluster because I will get a new public ip, right? Can I enforce a certificate creation within the deployment?

Best regards,
Stefan

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

StefanMiesem

I read the configfiles again an found that I misunderstood the change within the op-scim-deployment.yaml file. I had to remove the {} from the DNS name an publish the file again. But how can I debug, if something goes wrong? And are multiple pods supported, for high availability for example?

passwordlab

I also made the mistake. Hopefully that resolves my issue.

graham_1P

Just to chime in here, the op-scim service logs are always the first place to look when troubleshooting. Assuming your firewall is set to allow access to the pod, the cause of any SSL or LetsEncrypt error should show up in there.

Regarding multiple pods, you can run the SCIM Bridge with multiple pods but it will not change the availability of the service. As the service is essentially stateless and the Kubernetes deployment requires a running SCIM service, if either of the pods go down the kubernetes manager will bring a new one back up. There is an item of persistent storage included in the deployment where your scimsession file is written. When a new pod comes back up, it will read that file and then resume where it left off.

To be clear, the service isn't truly stateless. However it is pretty close: the only state transition is from startup while waiting for the bearer token from the first request, to running normally. In your logs you would see lines something like waiting for bearer token to begin provisioned user watcher while waiting, and then starting provisioned user watcher once the bearer token is received.