I'm in the process of implementing IdentityServer4 into my ASP.NET Core web application, which will be deployed to a Kubernetes cluster using Continuous Deployment.
The documentation talks about adding signing credentials (AddSigningCredential) and most tutorials/guides demonstrate how to use this by loading a .pfx file from the file system, or by using the local certificate store and searching by the subject name.
Is there a commonly accepted way of storing, retrieving and rotating the signing credentials when deployed to a Kubernetes cluster with minimal intervention?
I think using a secret is the best option in Kubernetes.
K8s have a secret kind that can be deployed with other ressource, here is a link to the official doc: https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/
Or you could also use another secret manager , like Vault.
If I am not mistaken , I think it's the best practice.
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.
I'm new to Hashicorp Vault. I am wondering if there is a way to take advantage of the SPIFFE protocol to automatically authenticate with Vault, so based on a vault client's mTLS certificate, a workload in Kubernetes/Istio can access Vault as a specific user (entity?) or group. The requesting k8s workload would only have access to Vault secrets based on its SPIFFE identity's Vault permissions.
I'm hoping that no Vault credentials (tokens, passwords, etc) would need to be passed and that access would be granted purely on the mTLS connection and the SPIFFE protocol. Is something like this possible? What are the options if Vault lives outside of the Kubernetes cluster (and therefore can't have an Istio sidecar)?
If what I'm asking is not possible, a less ideal solution would be to update the application code to somehow authenticate with Vault based on the pod's k8s Service Account. What are the options that Vault provides to do this type of thing? Are there any good resources regarding this?
I appreciate any advice you have to offer.
I have no knowledge about using SPIFFE for Vault authentcation, but I agree that it could be interesting (I'm not sure whether https://www.vaultproject.io/docs/auth/cert could help, but I never tried that).
As far as I know, the general way of integrating Kubernetes with Hashicorp Vault is described in https://www.vaultproject.io/docs/auth/kubernetes . It does not really matter where Vault is deployed: it can be inside the same Kubernetes cluster, in the same service mesh, or it can be a completely unrelated entity (e.g., a dedicated instance deployed on some random VM).
You basically define roles and policies on Vault, which are mapped to specific kubernetes service accounts and namespaces, and then the Kubernetes pod will be able to authenticate with the JWT that is associated to its service account.
Once Vault is setup and you can authenticate with Kubernetes pods, you can have any wrapper around it. People are trying to do this in different ways, but one possibility would be https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar . Personally, I'm using https://github.com/postfinance/vault-kubernetes because it fits my needs quite well.
The important part is setting up Vault to support Kubernetes properly: make sure to double check that first, before getting into any of these Kubernetes packages that try to fetch secrets.
I looked around IdentityServer4 official GitHub for configuring signing credential (certificate) for production, but i can't find any example. Specific thing for my environment is that it runs on Docker, so i need a cert to be generated in runtime for Linux machine, and then used for validating tokens.
In development mode i use AddDeveloperSigninCertificate helper in Startup.cs and it does the job, but i need a cert for production.
Did anyone have same issue?
Thanks!
Dear Cumulocity community,
i am developing a microservice for Cumulocity which needs some secret information (private key). One requirement is to store this information in a secure way. Which means encrypted and only access able by the microservice? During my research I found the possibility to define secrets at kubernetes: https://kubernetes.io/docs/concepts/configuration/secret/
Unfortunatly I am not familiar with kubernetes. Do i have the possibility to define secrets by using microservice-package-maven-plugin? Can i use this “secret” at all in Cumulocity? Has someone already used “secretes” in a hosted microservice?
Thank you in advanced, best regards
Kubernetes secrets aren't all that secret. They're accessible by any administrator, for example. Think of them as being convenient rather than secure.
Once you create a secret in Kubernetes, you can inject it into a pod as an environment variable, or as a file path. Check out the secrets docs and best practices.
If you are running Kubernetes in AWS or GCP, there are better ways, find a way to hook into the csp's key management systems, and you can have much more secure secret data.
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.