blob: 06a53a7946917bc55f2f19490f00f4111dc76b02 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
Container identity
Lead: Greg Castle
How are people using k8s service accounts
* Default service accounts?
* User:
* (Zalando)
* 55 clusters
* Only allow pre-set service accounts postgres "operator service accounts"
* Don’t enable RBAC
* Namespaces: usually use the default namespace, more sophisticated clients can use namespaces
* Cluster per product
* CRD that defines request for an OAuth2 token
* Q: Would you want to tie it to a Kubernetes service account. E.g. annotation on a service account to get an OAuth2 token
* (IBM)
* Strict way of "cutting up cluster"
* No team has access to the Kubernetes API
* Humans do, pods don’t
* Admins create service accounts and role bindings
* Issues with pod authors in the namespace can run any service account.
* Is there a missing binding to control the right to use a service account?
* Namespace boundary
* Application
* (VMware)
* 1 cluster
* Projects are per-namespace (200 namespaces)
* Wrote an admission controller between which pod is using which service account. Denies certain kind of changes.
* Ownership model "I created this object, only I can change it"
* Namespace but wanted sub-namespace primitives
* Service accounts have labels, need to match the pod.
* Q: Why not just different namespaces?
* Don’t want to give users the ability to create namespaces
* (Jetstat)
* Dev, staging, and prod cluster
* Namespace per team
* Their developers don’t have permissions to create workloads
* CI system is the thing that creates workloads, that controls stuff
* (CoreOS)
* Customers create namespaces that are controlled by CI/CD
* Users have read-access to cluster
* Central catalog controls the service account
* Authoritative on RBAC
* Catalog is currently controlled by CoreOS, can be used by users later
* Namespaces
* Catalog is enabled on a namespace
* Also use service accounts to authenticate CI/CD systems
* Container identity
* Authenticate workloads against each other
* Does this fit into the current way you use service accounts?
* What about envoy istio?
* Complementary efforts
* Services can do service to service auth
* Maybe not solving "I want to talk to s3, I want to talk to GitHub"
* Give them a better way to provision x509 certs
* Istio will be dependent on container identity
* Istio and SPIFFE?
* Istio is using SPIFFE conformant x509, not the workloads API
* Q: how does Zalando RBAC CRDs?
* Trust two engineers that have the permissions to create the CRDs
* Emergency procedure with time limited API
* Q: multiple clusters working together?
* IBM: going to face it
* CoreOS: thinking about users authenticating across multiple clusters through sharing public keys.
* Liggitt: namespaces are the boundaries of trust
* Originally thought about using pod templates so admins could create specific templates that pods MUST use.
* Reference pod template in RC or deployment instead of inlining them
* Never bubbled up to be the most important thing yet
* Liggitt: Kubernetes API isn’t really designed for things that hold credentials
* Moving the mounting and creation of the service account to the kubelet through flex volumes
* Helps you leverage the node level integrations
* Q: what about the secrets proposal?
* KMS is being added
* No change for encrypting the secret as you read it
* Slides
* Authorization should apply to the identity, rather than the namespace
* Is multiple SA per namespace an anti-pattern?
* Useful for bounding process within pods to certain permissions
* Problem when a SA from cluster scoped manifests
* Q: kerberos and vault bindings implemented as flex volumes
* Is it important to have standard identity mechanisms? (Yes)
* Can we add it to conformance?
* Avoid lock-in for IAM
* Cluster identity also becomes an issue too
* Pod/UID/Namespace/Cluster
* Potentially use OpenID Connect format so others can use that spec
|
