Skip to content

Commit 841abd6

Browse files
authored
Merge pull request #21960 from joshuabezaleel/id/configure-service-account
Add translation for configuring service account for ID localization
2 parents 989f5da + 00c186a commit 841abd6

File tree

2 files changed

+353
-0
lines changed

2 files changed

+353
-0
lines changed
Lines changed: 333 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,333 @@
1+
---
2+
title: Mengatur ServiceAccount untuk Pod
3+
content_type: task
4+
weight: 90
5+
---
6+
7+
<!-- overview -->
8+
ServiceAccount menyediakan identitas untuk proses yang sedang berjalan dalam sebuah Pod.
9+
10+
{{< note >}}
11+
Dokumen ini digunakan sebagai pengenalan untuk pengguna terhadap ServiceAccount dan menjelaskan bagaimana perilaku ServiceAccount dalam konfigurasi klaster seperti yang direkomendasikan Kubernetes. Pengubahan perilaku yang bisa saja dilakukan administrator klaster terhadap klaster tidak menjadi bagian pembahasan dokumentasi ini.
12+
{{< /note >}}
13+
14+
Ketika kamu mengakses klaster (contohnya menggunakan `kubectl`), kamu terautentikasi oleh apiserver sebagai sebuah akun pengguna (untuk sekarang umumnya sebagai `admin`, kecuali jika administrator klustermu telah melakukan pengubahan). Berbagai proses yang ada di dalam kontainer dalam Pod juga dapat mengontak apiserver. Ketika itu terjadi, mereka akan diautentikasi sebagai sebuah ServiceAccount (contohnya sebagai `default`).
15+
16+
17+
18+
19+
## {{% heading "prerequisites" %}}
20+
21+
22+
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
23+
24+
25+
26+
<!-- steps -->
27+
28+
## Menggunakan Default ServiceAccount untuk Mengakses API server.
29+
30+
Ketika kamu membuat sebuah Pod, jika kamu tidak menentukan sebuah ServiceAccount, maka ia akan otomatis ditetapkan sebagai ServiceAccount`default` di Namespace yang sama. Jika kamu mendapatkan json atau yaml mentah untuk sebuah Pod yang telah kamu buat (contohnya menggunakan `kubectl get pods/<podname> -o yaml`), kamu akan melihat _field_ `spec.serviceAccountName` yang telah secara [otomatis ditentukan](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
31+
32+
Kamu dapat mengakses API dari dalam Pod menggunakan kredensial ServiceAccount yang ditambahkan secara otomatis seperti yang dijelaskan dalam [Mengakses Klaster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
33+
Hak akses API dari ServiceAccount menyesuaikan dengan [kebijakan dan plugin otorisasi](/docs/reference/access-authn-authz/authorization/#authorization-modules) yang sedang digunakan.
34+
35+
Di versi 1.6+, kamu dapat tidak memilih _automounting_ kredensial API dari sebuah ServiceAccount dengan mengatur `automountServiceAccountToken: false` pada ServiceAccount:
36+
37+
```yaml
38+
apiVersion: v1
39+
kind: ServiceAccount
40+
metadata:
41+
name: build-robot
42+
automountServiceAccountToken: false
43+
...
44+
```
45+
46+
Di versi 1.6+, kamu juga dapat tidak memilih _automounting_ kredensial API dari suatu Pod tertentu:
47+
48+
```yaml
49+
apiVersion: v1
50+
kind: Pod
51+
metadata:
52+
name: my-pod
53+
spec:
54+
serviceAccountName: build-robot
55+
automountServiceAccountToken: false
56+
...
57+
```
58+
59+
Pengaturan dari spesifikasi Pod didahulukan dibanding ServiceAccount jika keduanya menentukan nilai dari `automountServiceAccountToken`.
60+
61+
## Menggunakan Beberapa ServiceAccount.
62+
63+
Setiap Namespace memiliki sumber daya ServiceAccount standar `default`.
64+
Kamu dapat melihatnya dan sumber daya serviceAccount lainnya di Namespace tersebut dengan perintah:
65+
66+
```shell
67+
kubectl get serviceaccounts
68+
```
69+
Keluarannya akan serupa dengan:
70+
71+
```
72+
NAME SECRETS AGE
73+
default 1 1d
74+
```
75+
76+
Kamu dapat membuat objek ServiceAccount tambahan seperti ini:
77+
78+
```shell
79+
kubectl apply -f - <<EOF
80+
apiVersion: v1
81+
kind: ServiceAccount
82+
metadata:
83+
name: build-robot
84+
EOF
85+
```
86+
87+
Nama dari objek ServiceAccount haruslah sebuah [nama subdomain DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) yang valid.
88+
89+
Jika kamu mendapatkan objek ServiceAccount secara komplit, seperti ini:
90+
91+
```shell
92+
kubectl get serviceaccounts/build-robot -o yaml
93+
```
94+
Keluarannya akan serupa dengan:
95+
96+
```
97+
apiVersion: v1
98+
kind: ServiceAccount
99+
metadata:
100+
creationTimestamp: 2015-06-16T00:12:59Z
101+
name: build-robot
102+
namespace: default
103+
resourceVersion: "272500"
104+
uid: 721ab723-13bc-11e5-aec2-42010af0021e
105+
secrets:
106+
- name: build-robot-token-bvbk5
107+
```
108+
109+
maka kamu dapat melihat bahwa _token_ telah dibuat secara otomatis dan dirujuk oleh ServiceAccount.
110+
111+
Kamu dapat menggunakan _plugin_ otorisasi untuk [mengatur hak akses dari ServiceAccount](/docs/reference/access-authn-authz/rbac/#service-account-permissions).
112+
113+
Untuk menggunakan ServiceAccount selain nilai standar, atur _field_ `spec.serviceAccountName` dari Pod menjadi nama dari ServiceAccount yang hendak kamu gunakan.
114+
115+
_Service account_ harus ada ketika Pod dibuat, jika tidak maka akan ditolak.
116+
117+
Kamu tidak dapat memperbarui ServiceAccount dari Pod yang telah dibuat.
118+
119+
Kamu dapat menghapus ServiceAccount dari contoh seperti ini:
120+
121+
```shell
122+
kubectl delete serviceaccount/build-robot
123+
```
124+
125+
## Membuat token API ServiceAccount secara manual.
126+
127+
Asumsikan kita memiliki ServiceAccount dengan nama "build-robot" seperti yang disebukan di atas, dan kita membuat Secret secara manual.
128+
129+
```shell
130+
kubectl apply -f - <<EOF
131+
apiVersion: v1
132+
kind: Secret
133+
metadata:
134+
name: build-robot-secret
135+
annotations:
136+
kubernetes.io/service-account.name: build-robot
137+
type: kubernetes.io/service-account-token
138+
EOF
139+
```
140+
141+
Sekarang kamu dapat mengonfirmasi bahwa Secret yang baru saja dibuat diisi dengan _token_ API dari ServiceAccount "build-robot".
142+
143+
Setiap _token_ dari ServiceAccount yang tidak ada akan dihapus oleh _token controller_.
144+
145+
```shell
146+
kubectl describe secrets/build-robot-secret
147+
```
148+
Keluarannya akan serupa dengan:
149+
150+
```
151+
Name: build-robot-secret
152+
Namespace: default
153+
Labels: <none>
154+
Annotations: kubernetes.io/service-account.name=build-robot
155+
kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
156+
157+
Type: kubernetes.io/service-account-token
158+
159+
Data
160+
====
161+
ca.crt: 1338 bytes
162+
namespace: 7 bytes
163+
token: ...
164+
```
165+
166+
{{< note >}}
167+
Isi dari `token` tidak dirinci di sini.
168+
{{< /note >}}
169+
170+
## Menambahkan ImagePullSecret ke ServiceAccount.
171+
172+
### Membuat imagePullSecret
173+
174+
- Membuat sebuah imagePullSecret, seperti yang dijelaskan pada [Menentukan ImagePullSecret pada Pod](/id/docs/concepts/containers/images/#tentukan-imagepullsecrets-pada-sebuah-pod).
175+
176+
```shell
177+
kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \
178+
--docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
179+
--docker-email=DUMMY_DOCKER_EMAIL
180+
```
181+
182+
- Memastikan bahwa Secret telah terbuat.
183+
```shell
184+
kubectl get secrets myregistrykey
185+
```
186+
187+
Keluarannya akan serupa dengan:
188+
189+
```
190+
NAME TYPE DATA AGE
191+
myregistrykey   kubernetes.io/.dockerconfigjson   1       1d
192+
```
193+
194+
### Menambahkan imagePullSecret ke ServiceAccount
195+
196+
Selanjutnya, modifikasi ServiceAccount standar dari Namespace untuk menggunakan Secret ini sebagai imagePullSecret.
197+
198+
199+
```shell
200+
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
201+
```
202+
203+
Sebagai gantinya kamu dapat menggunakan `kubectl edit`, atau melakukan pengubahan secara manual manifes YAML seperti di bawah ini:
204+
205+
```shell
206+
kubectl get serviceaccounts default -o yaml > ./sa.yaml
207+
```
208+
209+
Keluaran dari berkas `sa.yaml` akan serupa dengan:
210+
211+
```shell
212+
apiVersion: v1
213+
kind: ServiceAccount
214+
metadata:
215+
creationTimestamp: 2015-08-07T22:02:39Z
216+
name: default
217+
namespace: default
218+
resourceVersion: "243024"
219+
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
220+
secrets:
221+
- name: default-token-uudge
222+
```
223+
224+
Menggunakan _editor_ pilihanmu (misalnya `vi`), buka berkas `sa.yaml`, hapus baris dengan key `resourceVersion`, tambahkan baris dengan `imagePullSecrets:` dan simpan.
225+
226+
Keluaran dari berkas `sa.yaml` akan serupa dengan:
227+
228+
```shell
229+
apiVersion: v1
230+
kind: ServiceAccount
231+
metadata:
232+
creationTimestamp: 2015-08-07T22:02:39Z
233+
name: default
234+
namespace: default
235+
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
236+
secrets:
237+
- name: default-token-uudge
238+
imagePullSecrets:
239+
- name: myregistrykey
240+
```
241+
242+
Terakhir ganti serviceaccount dengan berkas `sa.yaml` yang telah diperbarui.
243+
244+
```shell
245+
kubectl replace serviceaccount default -f ./sa.yaml
246+
```
247+
248+
### Memverifikasi imagePullSecrets sudah ditambahkan ke spesifikasi Pod
249+
250+
Ketika Pod baru dibuat dalam Namespace yang sedang aktif dan menggunakan ServiceAccount, Pod baru akan memiliki _field_ `spec.imagePullSecrets` yang ditentukan secara otomatis:
251+
252+
```shell
253+
kubectl run nginx --image=nginx --restart=Never
254+
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'
255+
```
256+
257+
Keluarannya adalah:
258+
259+
```
260+
myregistrykey
261+
```
262+
263+
<!--## Menambahkan Secrets ke sebuah ServiceAccount.
264+
265+
TODO: Tes dan jelaskan bagaimana cara menambahkan Secret tambahan non-K8s dengan ServiceAccount yang sudah ada.
266+
-->
267+
268+
## ServiceAccountTokenVolumeProjection
269+
270+
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
271+
272+
{{< note >}}
273+
ServiceAccountTokenVolumeProjection masih dalam tahap __beta__ untuk versi 1.12 dan diaktifkan dengan memberikan _flag_ berikut ini ke API server:
274+
275+
* `--service-account-issuer`
276+
* `--service-account-signing-key-file`
277+
* `--service-account-api-audiences`
278+
279+
{{< /note >}}
280+
281+
Kubelet juga dapat memproyeksikan _token_ ServiceAccount ke Pod. Kamu dapat menentukan properti yang diinginkan dari _token_ seperti target pengguna dan durasi validitas. Properti tersebut tidak dapat diubah pada _token_ ServiceAccount standar. _Token_ ServiceAccount juga akan menjadi tidak valid terhadap API ketika Pod atau ServiceAccount dihapus.
282+
283+
Perilaku ini diatur pada PodSpec menggunakan tipe ProjectedVolume yaitu [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Untuk memungkinkan Pod dengan _token_ dengan pengguna bertipe _"vault"_ dan durasi validitas selama dua jam, kamu harus mengubah bagian ini pada PodSpec:
284+
285+
{{< codenew file="pods/pod-projected-svc-token.yaml" >}}
286+
287+
Buat Pod:
288+
289+
```shell
290+
kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
291+
```
292+
293+
_Token_ yang mewakili Pod akan diminta dan disimpan kubelet, lalu kubelet akan membuat _token_ yang dapat diakses oleh Pod pada _file path_ yang ditentukan, dan melakukan _refresh_ _token_ ketika telah mendekati waktu berakhir. _Token_ akan diganti oleh kubelet jika _token_ telah melewati 80% dari total TTL, atau jika _token_ telah melebihi waktu 24 jam.
294+
295+
Aplikasi bertanggung jawab untuk memuat ulang _token_ ketika terjadi penggantian. Pemuatan ulang teratur (misalnya sekali setiap 5 menit) cukup untuk mencakup kebanyakan kasus.
296+
297+
## ServiceAccountIssuerDiscovery
298+
299+
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
300+
301+
Fitur ServiceAccountIssuerDiscovery diaktifkan dengan mengaktifkan [gerbang fitur](/docs/reference/command-line-tools-reference/feature-gate) `ServiceAccountIssuerDiscovery` dan mengaktifkan fitur _Service Account Token Volume Projection_ seperti yang telah dijelaskan [di atas](#service-account-token-volume-projection).
302+
303+
{{< note >}}
304+
URL _issuer_ harus sesuai dengan _[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)_. Pada implementasinya, hal ini berarti URL harus menggunakan skema `https` dan harus menyediakan konfigurasi penyedia OpenID pada `{service-account-issuer}/.well-known/openid-configuration`.
305+
306+
Jika URL tidak sesuai dengan aturan, _endpoint_ `ServiceAccountIssuerDiscovery` tidak akan didaftarkan meskipun fitur telah diaktifkan.
307+
{{< /note >}}
308+
309+
Fitur _Service Account Issuer Discovery_ memungkinkan federasi dari berbagai _token_ ServiceAccount Kubernetes yang dibuat oleh sebuah klaster (penyedia identitas) dan sistem eksternal.
310+
311+
Ketika diaktifkan, server API Kubernetes menyediakan dokumen OpenID Provider Configuration pada `/.well-known/openid-configuration` dan JSON Web Key Set (JWKS) terkait pada `/openid/v1/jwks`. OpenID Provider Configuration terkadang disebut juga dengan sebutan _discovery document_.
312+
313+
Ketika diaktifkan, klaster juga dikonfigurasi dengan RBAC ClusterRole standar yaitu `system:service-account-issuer-discovery`. _Role binding_ tidak disediakan secara _default_. Administrator dimungkinkan untuk, sebagai contoh, menentukan apakah peran akan disematkan ke `system:authenticated` atau `system:unauthenticated` tergantung terhadap kebutuhan keamanan dan sistem eksternal yang direncakanan untuk diintegrasikan.
314+
315+
{{< note >}}
316+
Respons yang disediakan pada `/.well-known/openid-configuration` dan`/openid/v1/jwks` dirancang untuk kompatibel dengan OIDC, tetapi tidak sepenuhnya sesuai dengan ketentuan OIDC. Dokumen tersebut hanya berisi parameter yang dibutuhkan untuk melakukan validasi terhadap _token_ ServiceAccount Kubernetes.
317+
{{< /note >}}
318+
319+
Respons JWKS memuat kunci publik yang dapat digunakan oleh sistem eksternal untuk melakukan validasi _token_ ServiceAccount Kubernetes. Awalnya sistem eksternal akan mengkueri OpenID Provider Configuration, dan selanjutnya dapat menggunakan _field_ `jwks_uri` pada respons kueri untuk mendapatkan JWKS.
320+
321+
Pada banyak kasus, server API Kubernetes tidak tersedia di internet publik, namun _endpoint_ publik yang menyediakan respons hasil _cache_ dari server API dapat dibuat menjadi tersedia oleh pengguna atau penyedia servis. Pada kasus ini, dimungkinkan untuk mengganti `jwks_uri` pada OpenID Provider Configuration untuk diarahkan ke _endpoint_ publik sebagai ganti alamat server API dengan memberikan _flag_ `--service-account-jwks-uri` ke API server. serupa dengan URL _issuer_, URI JWKS diharuskan untuk menggunakan skema `https`.
322+
323+
324+
## {{% heading "whatsnext" %}}
325+
326+
327+
Lihat juga:
328+
329+
- [Panduan Admin Kluster mengenai ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/)
330+
- [ServiceAccount Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
331+
- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)
332+
333+
Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
apiVersion: v1
2+
kind: Pod
3+
metadata:
4+
name: nginx
5+
spec:
6+
containers:
7+
- image: nginx
8+
name: nginx
9+
volumeMounts:
10+
- mountPath: /var/run/secrets/tokens
11+
name: vault-token
12+
serviceAccountName: build-robot
13+
volumes:
14+
- name: vault-token
15+
projected:
16+
sources:
17+
- serviceAccountToken:
18+
path: vault-token
19+
expirationSeconds: 7200
20+
audience: vault

0 commit comments

Comments
 (0)