Add on-prem Kubernetes OIDC to Azure blog post #555
Conversation
| - OIDC | ||
| --- | ||
|
|
||
| I've been learning Kubernetes. I started with an on-premises single-node cluster and later moved on to Azure Kubernetes Service (AKS). Setting up a basic setup in both was quite straightforward, and I got a simple web API hosted rather quickly. |
There was a problem hiding this comment.
The introduction to this blog post is a bit long. Could you hook the reader with a sentence or two before explaining in more detail, how you came to this question and doing this blog post? I know it is in excerpt, but would be good in the beginning here also.
There was a problem hiding this comment.
Maybe also, what can be achieved if this kind of trick can be done. What is possible and what are the benefits, if you pull this off :)
There was a problem hiding this comment.
Had an idea on lunch that maybe drawing picture with all the actors in place. Then drawing arrows how things usually get authenticated and how this setup changes that picture. For example red crosses over some arrows of green arrows pointing to another issuer or something. + one example below and readers would get the picture what kind of benefits this implementation would have.
There was a problem hiding this comment.
- I shortened the introduction significantly
- I added the benefits of using this kind of authentication
But I didn't add a picture
|
|
||
| I started by getting a pod running with a projected service account token, to see the actual contents of a token, not the examples from the Internet. The Kubernetes [service account token projection page](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection) has an almost-ready YAML, I just needed to create the service account too. YAML for the service account was available on the same page. | ||
|
|
||
| The token (decoded token payload below, irrelevant properties removed) looked the same as in the examples. So, from a cluster configuration point of view, all I need to change is the _issuer_ (_iss_). Based on the OpenID Connect (OIDC) [spec](https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery), the value can be any URL address, as long as it has https scheme, has no query or fragment part in it, and you're able to host content under that. The address may contain a path component, e.g., _https://domain.tld/tenant1_ is allowed. The **cluster doesn't need to be hosted in that address**! In the AWS instructions, they set the _issuer_ to be an S3 bucket, as that's one easy way to host relevant documents. |
There was a problem hiding this comment.
Maybe splitting sentence starting "Based on the OpenID Connect (OIDC)..." to two. So many commas in it so it can get difficult to read.
There was a problem hiding this comment.
Converted the long sentence into a list
|
|
||
| ## Configure Azure user-assigned managed identity | ||
|
|
||
| Three things needed to be done in Azure. First, I created a user-assigned managed identity. You can also use an app registration and a service principal, but I used a managed identity. |
There was a problem hiding this comment.
Three things needs to be done for what? :)
This chapter needs some editing. Some muscle around bones. I think it might jump too fast to the point.
There was a problem hiding this comment.
Added "an introduction" to the chapter
|
|
||
| ## Necessary code changes | ||
|
|
||
| I actually wouldn't have needed to do any code changes, since I already had the following code from my AKS experiment: |
There was a problem hiding this comment.
Here also. Some little. Like just a half-sentence introduction to the topic what code changes in where.
There was a problem hiding this comment.
Added "an introduction" to the chapter.
|
|
||
| The next step was to convert the key to _PKCS #8_ format. When trying to convert the existing key, I got _Load key ".../sa.pub": error in libcrypto_ error. To make sure the instructions were right, I decided to generate a new key pair and try again. That time the conversion worked. I then compared the converted key to the public key file I was trying to convert. They looked almost identical, so I figured the key was already in _PKCS #8_ format. I just had to hope that it wouldn't come and bite me later on... | ||
|
|
||
| Then I needed to run the public key through another [conversion tool](https://github.com/aws/amazon-eks-pod-identity-webhook/blob/master/hack/self-hosted/main.go), provided in the AWS pod identity webhook repository. The conversion tool was written in Go, but I didn't have Go installed, and I didn't want to install it for a single run. So, I used _golang_ Docker image, cloned the repository there (git was pre-installed), and ran the code in the container. The hardest part was getting the existing public key to the container, as _golang_ image didn't have `nano` or `vim` installed. So, I did some searching and found `cat <<EOF> filename` trickery (apparently it's called [_here document_](https://en.wikipedia.org/wiki/Here_document)). I had seen it before, but hadn't used it before, except for some individual copy-pastes from tutorials. |
There was a problem hiding this comment.
I might get missed this, but why public key needs to be run through another conversion?
There was a problem hiding this comment.
Added a description why two conversions are needed
3 participants
No description provided.