One of the hardest things to do in K8s and other orchestrators (amongst others) is certificate management. And this isn't just at the ingress. Best practices say that all coms within your k8s cluster should be encrypted and you should be using certificate validation because of the hacks against containers that can compromise your entire cluster.
There is a solution to this in the k8s world: cert-manager. And in Azure it's KeyVault certificates.
In an ideal world, we would be able to define in Aspire Host something like the following:
var ca = .AddCA({some params});
Then, on each Micro Service/Resource add
.AddSigningCert(ca)
.AddCommsCert(ca)
And then
.AddYarp()
.AddSigningCert(ca)
.AddPublicCert(domains, or whatever)
For developers, what this would do is use step-ca or something similar in a docker container, and then spin the certs from there for the whole thing, and on the Yarp ingress those certs would be added to trust on every platform (I know, hard on Linux, but do it anyhow please)
And this would then generate the manifest information that would be necessary for Azure/AWS/Aspirate etc. to create the ingress, and setup all of the tooling internally and map it.
I.e. in K8s this would spin cert-manager, define the CA resource, define certificates for each of the micro services spun from the cert-manager CA, setup Yarp for ingress, define all of the micro-services endpoints on that Yarp instance, and use cert-manager to acquire the cert from Azure KeyVault/let's encrypt/AWS's version etc.
You would be a hero if this worked, and you'd be providing people with a HUGE reason to use C# in the world of micro-services and orchestration.
While I understand this is probably not doable for V1, it would be the next major win for V2 to have this because it squares the circle of everything other than just plain secrets and configmaps and is THE hardest thing to get right in this space.
One of the hardest things to do in K8s and other orchestrators (amongst others) is certificate management. And this isn't just at the ingress. Best practices say that all coms within your k8s cluster should be encrypted and you should be using certificate validation because of the hacks against containers that can compromise your entire cluster.
There is a solution to this in the k8s world: cert-manager. And in Azure it's KeyVault certificates.
In an ideal world, we would be able to define in Aspire Host something like the following:
var ca = .AddCA({some params});
Then, on each Micro Service/Resource add
.AddSigningCert(ca)
.AddCommsCert(ca)
And then
.AddYarp()
.AddSigningCert(ca)
.AddPublicCert(domains, or whatever)
For developers, what this would do is use step-ca or something similar in a docker container, and then spin the certs from there for the whole thing, and on the Yarp ingress those certs would be added to trust on every platform (I know, hard on Linux, but do it anyhow please)
And this would then generate the manifest information that would be necessary for Azure/AWS/Aspirate etc. to create the ingress, and setup all of the tooling internally and map it.
I.e. in K8s this would spin cert-manager, define the CA resource, define certificates for each of the micro services spun from the cert-manager CA, setup Yarp for ingress, define all of the micro-services endpoints on that Yarp instance, and use cert-manager to acquire the cert from Azure KeyVault/let's encrypt/AWS's version etc.
You would be a hero if this worked, and you'd be providing people with a HUGE reason to use C# in the world of micro-services and orchestration.
While I understand this is probably not doable for V1, it would be the next major win for V2 to have this because it squares the circle of everything other than just plain secrets and configmaps and is THE hardest thing to get right in this space.