Skip to content

add proposal about container-level serviceaccount #2497

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

add proposal about container-level serviceaccount #2497

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0f8ec7e
add description about container-level serviceaccount
WanLinghao Aug 8, 2018
268b33e
Fix descriptions
WanLinghao Feb 11, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion contributors/design-proposals/auth/bound-service-account-tokens.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,9 @@ tokens will be drop in replacements for the current service account tokens.
Tokens issued from this API may be bound to a Kubernetes object in the same
namespace as the service account. The name, group, version, kind and uid of the
object will be embedded as claims in the issued token. A token bound to an
object will only be valid for as long as that object exists.
object will only be valid for as long as that object exists. The token will contain
which container the request comes from if ContainerName was specified. ContainerName
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without a consistent enforcement mechanism to guarantee these tokens are only used in requests from that container, I don't think we can make that claim

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kubernetes/kubernetes#61858 insert pod information into user.Info.Extra() , and we could not make sure the tokens are only used in requests from that pod neither. So what's the difference between the container information and pod information. I am a little confused about this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those assert what pod the token was created for, they do not assert that is where the request is coming from

will only be valid when BoundObjectReference.Kind is 'Pod'.

Only a subset of object kinds will support object binding. Initially the only
kinds that will be supported are:
Expand Down Expand Up @@ -105,6 +107,10 @@ type TokenRequestSpec struct {
// BoundObjectRef is a reference to an object that the token will be bound to.
// The token will only be valid for as long as the bound object exists.
BoundObjectRef *BoundObjectReference

// ContainerName indicates which container the token will be bound to. Valid
// when BoundObjectRef is Pod.
ContainerName string
}

type BoundObjectReference struct {
Expand Down Expand Up @@ -165,6 +171,7 @@ type TokenReviewSpec struct {
> "apiVersion": "v1",
> "name": "pod-foo-346acf"
> }
> "containerName": "foo-container",
> }
> }
{
Expand All @@ -180,6 +187,7 @@ type TokenReviewSpec struct {
"apiVersion": "v1",
"name": "pod-foo-346acf"
}
"containerName": "foo-container"
},
"status": {
"token":
Expand Down Expand Up @@ -209,6 +217,7 @@ The token payload will be:
"uid": "a4bb8aa4-0168-11e8-92e5-42010af00002",
"name": "pod-foo-346acf"
}
"containerName": "foo-container"
}
}
```
Expand Down
6 changes: 5 additions & 1 deletion contributors/design-proposals/storage/svcacct-token-volume-source.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80,6 +80,9 @@ type ServiceAccountTokenProjection struct {
ExpirationSeconds int64
// Path is the relative path of the file to project the token into.
Path string
// If true, the token this volume contains would include informations about
// which container the token will mount on.
IsContainerLevel bool
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would mean the kubelet would have to fan out and maintain N tokens for a pod with N containers... is that what we want?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@liggitt For most use cases who don't need container-level serviceaccount feature, they just launch a token projection volume with IsContainerLevel being false. In this case, all the containers could share single serviceaccount token.

}
```

Expand All @@ -88,7 +91,8 @@ sourced from the TokenRequest API into volumes created from
ProjectedVolumeSources. As the token approaches expiration, the kubelet volume
plugin will proactively rotate the service account token. The kubelet will start
trying to rotate the token if the token is older than 80 percent of its time to
live or if the token is older than 24 hours.
live or if the token is older than 24 hours. If IsContainerLevel is true, the
volume should be used by single container exclusively.

To replace the current service account token secrets, we also need to inject the
clusters CA certificate bundle. Initially we will deploy to data in a configmap
Expand Down