Is there built-in support for enabling SSL on Azure Container Instances? If not, can we hook up to SSL providers like Lets Encrypt?
There is nothing built-in today. You need to load the certs into the container and terminate SSL there. Soon, we will enable support for ACI containers to join an Azure virtual network, at which point you could front your containers with Azure Application Gateway and terminate SSL there.
As said above, no support today for built-in SSL when using ACI. I'm using Azure Application Gateway to publish my container endpoint using the HTTP-to-HTTPS bridge. This way, App Gateway needs a regular HTTPS cert (and you can use whichever model works best for you as long as you can introduce a .PFX file during provisioning or later during configuratiorn) and it will then use HTTP to talk to your (internally facing) ACI-based container. This approach becomes more secure if you bind your ACI-based container to a VNET and restrict traffic from elsewhere.
To use SSL within the ACI-container you'd need to introduce your certification while provisioning the container, and then somehow automate certificate expiration and renewal. As this is not supported in a reasonable way, I chose to use the App Gateway to resolve this. You could also use API Management but that is obviously slightly more expensive and introduces a lot more moving parts.
I blogged about this configuration here and the repo with provisioning scripts is here.
You can add SSL support at the API Gateway and simply configure the underlying API over HTTP.
You will need the secrete key to execute above api method!
You can access the underlying API hosted at the Azure Container Instance. This method does not require jwt token as this is a demo api.
Related
I'm running a Kubernetes cluster in AKS with Traefik as Ingress controller. I have cert-manager to automatically generate and renew certificates from Let's encrypt. It's a SaaS application, so users can choose to configure their own domain names. So for example, the "generic" URL would be mysaas.com, bust customers can choose to use something like customer.com and CNAME that to mysaas.com instead, and cert-manager will generate a cert for customer.com.
I'm currently looking at placing a WAF in front of all of this, and since I'm running in Azure I'm looking at Azure Application Gateway more specifically.
What I'm trying to figure out now, is how to automate configuration of the certs in the Application Gateway as well, so that it can decrypt/encrypt the traffic. These are the things I'm trying to figure out how to do (if they're even possible):
Automate upload of certs to Azure KeyVault and let Application Gateway read them from there
Con: Not sure how to do this
Pro: Cert management is still handled by cert-manager which I trust
Automate upload of certs directly to Application Gateway
Con: Not sure how to do this
Pro: Cert management is still handled by cert-manager which I trust
Skip encryption between Application Gateway and the AKS cluster and let Application Gateway handle generation/renewal of certs.
I would have to make the cluster private, but I guess that's a good thing.
Pro: Nice not having two things depend on the certs (Traefik and Application Gateway)
Con: The current setup using cert-manager works fine and I have monitoring in place for that. I'm not sure I can get a setup as nice as that using only Application Gateway, and I don't know if it's even possible.
I know that the Azure Application Gateway Ingress Controller exists, but I really like the setup with Traefik that I have in place today, and frankly there are too many things that scare me a bit about the AGIC.
We need to protect our reserved instance of IBM API Connect that we have in the Cloud with a WAF of our own company and we do not know if this is possible and the steps to perform or if it is only possible with a WAF of IBM's own cloud.
thanks in advance
For this answer, I'm going to assume you're asking primarily about the DataPower API Gateway.
You can either deploy your own gateway in an environment of your choosing (i.e. you're managing it) or leverage the one that IBM provides to you by default.
If you deploy your own, then you control the networking and adding your own WAF is relatively straightforward.
If you use an IBM-managed gateway, then a little creativity is required. You would likely need to set up a Mutual TLS contract between your WAF and the Gateway. You'd terminate the incoming TLS connection at the WAF (e.g. Cloudflare) and then re-encrypt the traffic from the WAF to the Gateway using the client certificate exchange. You'd potentially need to apply a Mutual TLS-enforcing profile to each deployed API on the Gateway. In this scenario, no client can call an API on your gateway without the proper TLS client key/certificate in hand.
You may want to open a support ticket for further/deeper assistance on this topic.
I have an application that is internal and exposed only to other application on the cluster by a service with cluster IP. Other services are accessing this application via it's DNS (serviceName-namespace.svc.cluster.local). This application handles sensitive data, so although all the communication is inside the cluster I would like to use TLS to secure the communications to this application.
My question is - how can I enable TLS on a service? Is there something already exist or should I handle it on the application code? Also, is there already a CA I can use on the cluster that can sign certificates for .svc.cluster.local?
To clarify, I know I can use ingress for this purpose. The only problem is keeping this service internal only - so only services inside the cluster will be able to access it.
Thanks,
Omer
I just found that Kubernetes API can be used to generate a certificate that will be trusted by all the pods running on the cluster. This option might be simpler than the alternatives. You can find the documentation here, including full flow of generating a certificate and using it.
Following #vonc comments from bellow, I think I have a solution:
Purchase a public valid domain for this service (e.g. something.mycompany.com).
Use CoreDNS to add override rule so all requests to something.mycompany.com will go to something-namesapce.svc.cluster.local, as the service is not exposed externally (this can be done also with normal A record for my use case).
Use Nginx or something else to handle TLS with the certificate for something.mycompany.com.
This sounds pretty complicated but might work. What do you think?
Check if the tutorial "Secure Kubernetes Services with Ingress, TLS and LetsEncrypt" could apply to you:
Ingress can be backed by different implementations through the use of different Ingress Controllers. The most popular of these is the Nginx Ingress Controller, however there are other options available such as Traefik, Rancher, HAProxy, etc. Each controller should support a basic configuration, but can even expose other features (e.g. rewrite rules, auth modes) via annotations.
Give it a domain name and enable TLS. LetsEncrypt is a free TLS certificate authority, and using the kube-lego controller we can automatically request and renew LetsEncrypt certificates for public domain names, simply by adding a few lines to our Ingress definition!
In order for this to work correctly, a public domain name is required and should have an A record pointing to the external IP of the Nginx service.
For limiting to inside the cluster domain though (svc.cluster.local), you might need CoreDNS.
On Google Cloud you can make load balancer service internal, like this:
annotations = {
"cloud.google.com/load-balancer-type" = "Internal"
}
I have been reading the Openshift documentation for secured (SSL) routes.
Since I use a free plan, I can only have an "Edge Termination" route, meaning the SSL is ended when external requests reach the router, with contents being transmitted from the router to the internal service via HTTP.
Is this secure ? I mean, part of the information transmission is done via HTTP in the end.
The connection between where the secure connection is terminated and your application which accepts the proxied plain HTTP request is all internal to the OpenShift cluster. It doesn't travel through any public network in the clear. Further, the way the software defined networking in OpenShift works, it is not possible for any other normal user to see that traffic, nor can applications running in other projects see the traffic.
The only people who might be able to see the traffic are administrators of the OpenShift cluster, but the same people could access your application container also. Any administrators of the system could access your application container even if using a pass through secure connection terminated with your application. So is the same situation as most managed hosting, where you rely on the administrators of the service to do the right thing.
I apologize if I am asking something too obvious, but I as understand SSL should be used when making API calls to remote apps. This particularly important if you are using a password or API key in the calls so networking sniffing doesn't reveal the details.
Having said that, if I have a Cloud-hosted app, e.g. AWS hosted PHP script, that makes a call to a MongoDB database hosted by a third-party provider e.g. ObjectRocket, do I need SSL between the two?
Secondly, as I understand if both the apps are hosted on the same infrastructure, e.g. Heroku (which AWS-based) and a third-party MongoDB provider (if they use AWS of the same region) then SSL is redundant when connecting from a Heroku-hosted app to the the database as AWS will prevent networking sniffing.
Thank you for your help. I appreciate anyone who can provide some fundamental information here.