search

IBM / cis-integration

The goal of this project is to automate CIS integration for IBM Cloud application platforms. We will produce a command-line tool that customers can use to simplify this process.
Apache License 2.0
3 stars 0 forks source link

Creating Certificates as Secrets #10

Closed akuljos closed 3 years ago

akuljos commented 3 years ago

This pull request introduces the capability to create certificates as part of the secrets of our cluster. It pulls the CRN from the Certificate Manager created by the user and uses that as well as the ID of the necessary cluster to import the certificate into the cluster as a secret in preparation for IKS integration.

akuljos commented 3 years ago

Although we've added the certificate to IKS as a secret, it seems as though we should be ordering a certificate for our client (if it doesn't exist). We may assume that the client has already provisioned a Certificate Manager instance (as creating an IKS cluster instance auto-provisions that); we simply have to access that manager and order a certificate, and then proceed with linking it to the IKS cluster.

akuljos commented 3 years ago

I've written pretty much all of the code for ordering a certificate (issued by Let's Encrypt) and creating a secret in the IKS cluster using that certificate. All of this is done without going through the CIS (and without ordering a certificate there).

There is one caveat though: I cannot change the expiration time through only the Certificate Manager, so it will remain at 90 days. I have turned "auto-renewal" on, but if we want a 15-year expiration time like the certificates we ordered manually, we have to go through CIS, which I can definitely code up, but it seems like a little more hassle for our client.

Thoughts on which method to use?

Pseusco commented 3 years ago

I've written pretty much all of the code for ordering a certificate (issued by Let's Encrypt) and creating a secret in the IKS cluster using that certificate. All of this is done without going through the CIS (and without ordering a certificate there).

There is one caveat though: I cannot change the expiration time through only the Certificate Manager, so it will remain at 90 days. I have turned "auto-renewal" on, but if we want a 15-year expiration time like the certificates we ordered manually, we have to go through CIS, which I can definitely code up, but it seems like a little more hassle for our client.

Thoughts on which method to use?

The certificate auto-renews at no cost to the user so I don't think it should be a problem

akuljos commented 3 years ago

Lucas and I have resolved the 500 error that arose when trying to import a certificate that had just been ordered by the certificate manager. If we tried right away, like I had done previously, the import resulted in a 500 error; however, after Lucas introduced a loop to ensure that the certificate was no longer pending, the certificate was imported correctly as a secret.

akuljos commented 3 years ago

Daroush mentioned that we should provide an option for the user to specify their namespace; this functionality shouldn't be too difficult to add (just another argument in the CLI tool).

Chris-Springstead commented 3 years ago

Looks good. One thing that we could maybe look into is a different CA to provide the certificate if the rate limiting does become a bigger problem in the future. However, when looking at the certificate order screen it seems like Lets Encrypt is the only option... so we might be limited there.

akuljos commented 3 years ago

Yep, unfortunately, we can't add functionality for other certificate providers unless the SDK is changed so that it allows for those providers. However, as of now, I feel like the rate-limiting shouldn't be too big of a problem for clients; the only reason we were getting rate-limited was that we were ordering certificates over and over again, which is something our client would not have to do.