Article: Authenticating microservices requests in Kubernetes #327

amitsaha · 2020-11-11T03:04:26Z

Preview: https://deploy-preview-327--learnk8s.netlify.app/microservices-authentication-kubernetes

src/microsAuthentication/content.md

danielepolencic · 2020-11-17T04:35:04Z

src/microsAuthentication/content.md

+Now, go back to the previous terminal window with the API service and issue the same request again:
+
+```terminal|command=1|title=bash
+curl <insert URL from above>


If we don't amend the Service earlier, this should container an example of the output above instead of <>

src/microsAuthentication/content.md

danielepolencic · 2020-11-17T04:35:32Z

src/microsAuthentication/content.md

+You can issue a request with:
+
+```terminal|command=1|title=bash
+curl <insert URL from above>


If we don't amend the Service earlier, this should container an example of the output above instead of <>

src/microsAuthentication/content.md

amitsaha · 2020-11-19T10:18:20Z

@danielepolencic it looks like you have made most of the changes you were thinking of - I made a few more edits.

I am not sure why the article isn't showing up in the preview.

src/microsAuthentication/content.md

danielepolencic · 2020-11-20T13:56:08Z

src/microsAuthentication/content.md

+```
+
+In this case, the token you will use to authenticate to the API server as well as verify the status
+of is the same. Thus, the curl command to run in the pod shell session is:


Is this sentence necessary? When is the token not the same?
I'm a bit confused since the assumption is that I need only 1 token.

@danielepolencic Consider the the 2nd demo - where the secret store is going to verify whether the token presented to it via the calling service (API) is legit or not. The secret store uses its own SA token to authenticate itself to the API when it makes a TokenReview request to validate the API token. In that case, the token being verified is different from the token being used to authenticate itself.

I'm tempted to explain that when we get to it.
It's easier if we make the content progressively more complex than presenting all the complexity upfront.
Thoughts?

src/register.ts

danielepolencic · 2020-11-21T02:08:57Z

src/microsAuthentication/content.md

+
+You can solve the above problems by implementing solutions such as mutual TLS or using a JWT based solution with a central authority server.
+
+However, in Kubernetes, you can use the service account token volume projection feature to create time-bound and audience-specific service account tokens which do not persist in the cluster store.


which do not persist in the cluster store

Not sure what this means. the two features listed do not imply that the data is not stored?

danielepolencic · 2020-11-21T02:10:05Z

src/microsAuthentication/content.md

+
+The Kubernetes API server performs the role of the central authority server and you don't have to worry about any of the internal details of expiring the tokens and more.
+
+This feature was introduced in Kubernetes 1.12 and gained further improvements in 1.13 and provides a more secure alternative to workload-specific service accounts.


Missing link to verify the claim. Official link to the doc would be nice.

danielepolencic · 2020-11-21T03:19:44Z

src/microsAuthentication/content.md

+
+```go
+result, err := clientset.AuthenticationV1().TokenReviews().Create(ctx, &tr, metav1.CreateOptions{})
+```


You broke the code line-by-line.
The idea is good, but I think it could be refactored to provide more context.
Keep the line by line, but should the snippet truncated in full.
Then use highlight in the code snippet to highlight specific parts.
In that way you offer context, but you can explain individual parts.

danielepolencic · 2020-11-21T08:29:46Z

src/microsAuthentication/content.md

+kube-system   system:persistent-volume-provisioner             2020-11-20T22:04:53Z
+```
+
+In the following example, you will use the `system:auth-delegator` role which has all the permission you need to call the Token Review API.


There's no system:auth-delegator when I list the roles. Not even in the table above. How did you create that?

danielepolencic · 2020-11-21T08:44:59Z

A few general notes:

there are three components: API, data store and secret store. However, the tutorial covers only 2: API + secret store. I think we should remove the data store. Or (even better), we could remove the data store and rename the secret store to data store. At the moment there's a lot of "secret" in the article. Sometimes it's the secret store, sometimes it's kubernetes. If we remove the word secret from the apps, there's no doubt about what secrets we are talking about.
ca.crt, system:auth-delegator need clarifications. I don't have those in my minikube.
We ask to open 3 terminal windows, but we do nothing with them. I think from the current copy, two are enough.
I'd like to figure out why the "projected volume" is called as such.
I will add some background (and picture) about Role/ClusterRole.
ClusterRoleBindings use an old API which displays an error in 1.19
Authentication is not authorization, but the article seems to use the terms interchagably. I think the TokenReview API is authentication, but when you use to verify the audience you are implementing custom authorization.

amitsaha · 2020-11-24T01:09:14Z

src/microsAuthentication/content.md

+
+You're issueing a request using your own account (cluster admin) and validating the token for a Service account.
+
+It's easier to explain, and we skip the part where we connect to the API. The same part is skipped in the Go client too (it's part of the SDK).


Nice find! I think i see your point here - not showing you to access the API directly.

How about we use kubectl to show the token review operation but use the token for the service token instead via the --token argument?

In addition can we still keep the curl bit?

Could you show me an example?

How about we use kubectl to show the token review operation but use the token for the service token instead via the --token argument?

# TODO: Get the token from the secret object kubectl apply -f t.yaml --token <token from above>

amitsaha · 2020-11-24T02:50:41Z

I think the TokenReview API is authentication, but when you use to verify the audience you are implementing custom authorization.

Completely agree with this. So should we just use authentication throughout?

danielepolencic · 2020-11-24T03:10:13Z

Completely agree with this. So should we just use authentication throughout?
I think we need to pay more attention, particularly at the beginning. It's ok to say authorization where we do auth.

amitsaha · 2020-11-24T05:08:36Z

@danielepolencic i made a few updates related to authn/authz what do you think?

Address review comment related to exposing the services from the manifest itself.

amitsaha mentioned this pull request Nov 11, 2020

Authenticating microservices requests in Kubernetes #326

Closed

danielepolencic reviewed Nov 17, 2020

View reviewed changes

src/microsAuthentication/content.md Outdated Show resolved Hide resolved

danielepolencic reviewed Nov 20, 2020

View reviewed changes

src/microsAuthentication/content.md Show resolved Hide resolved

danielepolencic reviewed Nov 20, 2020

View reviewed changes

amitsaha commented Nov 20, 2020

View reviewed changes

src/register.ts Show resolved Hide resolved

danielepolencic reviewed Nov 21, 2020

View reviewed changes

amitsaha commented Nov 24, 2020

View reviewed changes

danielepolencic force-pushed the micro_authentication branch from 4a9fb0d to 42378c6 Compare November 24, 2020 13:38

asaha123 and others added 13 commits November 25, 2020 11:21

init

ff9ae06

Update micros-authentication.tsx

81e366e

Update content.md

c63dba6

Add files via upload

613eca8

Update content.md

da8268d

Delete yaml-validate.png

9d46295

Delete yaml-validate.svg

3906231

Update content.md

949b146

Update content.md

6dcd5ab

Update content.md

37802a3

Update content.md

b62f85a

Update content.md

00682c7

Update content.md

ee06315

danielepolencic and others added 24 commits November 25, 2020 11:21

fixed formatting

f03ac55

reviewed intro

88b4647

amended SA, added examples

28b1220

update

77a65fd

Fix spelling of namespace

897be71

Update content.md

7fb10e6

Minor updates

d111128

reviewed

84506a7

Update deployment manifest to expose service

2b4ca4d

Address review comment related to exposing the services from the manifest itself.

update

1e033f5

reviewed

b2a0192

reviewed

2c74665

review

c1787a5

reviewed

1638a47

poc for impersonation api + kubectl

2d56c94

Update content.md

058d73c

formatting

d77108e

reviewing tokens with kubectl

5087aa5

Authentication/Authorization

0a76760

amended token review

585ecc8

removed demo SA

4eb6ad5

re-arrenged permissions

3bd755d

reviewed intro

6daf752

Add support for highlight in terminal blocks

c187d92

amitsaha force-pushed the micro_authentication branch from 87f809d to c187d92 Compare November 25, 2020 01:42

danielepolencic and others added 5 commits November 25, 2020 11:16

reviewed

2a1cf1d

Add link to 1.20 GA

26858fa

TokenReview code rearrange

bcadceb

fix

aba3516

Update logs to be prettier

52ba4d2

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Article: Authenticating microservices requests in Kubernetes #327

Article: Authenticating microservices requests in Kubernetes #327

amitsaha commented Nov 11, 2020 •

edited by danielepolencic

Loading

danielepolencic Nov 17, 2020

danielepolencic Nov 17, 2020

amitsaha commented Nov 19, 2020

danielepolencic Nov 20, 2020

amitsaha Nov 20, 2020

danielepolencic Nov 21, 2020

danielepolencic Nov 21, 2020

danielepolencic Nov 21, 2020

danielepolencic Nov 21, 2020

danielepolencic Nov 21, 2020

danielepolencic commented Nov 21, 2020 •

edited

Loading

amitsaha Nov 24, 2020

danielepolencic Nov 24, 2020

amitsaha Nov 24, 2020 •

edited

Loading

amitsaha commented Nov 24, 2020

danielepolencic commented Nov 24, 2020

amitsaha commented Nov 24, 2020


		You can solve the above problems by implementing solutions such as mutual TLS or using a JWT based solution with a central authority server.

		However, in Kubernetes, you can use the service account token volume projection feature to create time-bound and audience-specific service account tokens which do not persist in the cluster store.


		The Kubernetes API server performs the role of the central authority server and you don't have to worry about any of the internal details of expiring the tokens and more.

		This feature was introduced in Kubernetes 1.12 and gained further improvements in 1.13 and provides a more secure alternative to workload-specific service accounts.


		You're issueing a request using your own account (cluster admin) and validating the token for a Service account.

		It's easier to explain, and we skip the part where we connect to the API. The same part is skipped in the Go client too (it's part of the SDK).

Article: Authenticating microservices requests in Kubernetes #327

Are you sure you want to change the base?

Article: Authenticating microservices requests in Kubernetes #327

Conversation

amitsaha commented Nov 11, 2020 • edited by danielepolencic Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amitsaha commented Nov 19, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielepolencic commented Nov 21, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amitsaha Nov 24, 2020 • edited Loading

Choose a reason for hiding this comment

amitsaha commented Nov 24, 2020

danielepolencic commented Nov 24, 2020

amitsaha commented Nov 24, 2020

amitsaha commented Nov 11, 2020 •

edited by danielepolencic

Loading

danielepolencic commented Nov 21, 2020 •

edited

Loading

amitsaha Nov 24, 2020 •

edited

Loading