特に指定されていない場合、ポッドはネームスペースのデフォルトのサービスアカウントで実行されます。デフォルトのサービスアカウントに許可されていることを確認するにはどうすればよいですか?すべてのポッドにマウントする必要がありますか?名前空間レベルまたはクラスターレベルでこの動作を無効にします。
それでもドキュメントを検索しています。
環境:RBACを使用したKubernetes 1.12
デフォルトのサービスアカウントが処理すべきその他のユースケースは何ですか? namsaceaceでk8s展開を作成および管理するためのサービスアカウントとして使用できますか/使用できますか? 、たとえば、ユーザーがチーム/組織に出入りするため、実際のユーザーアカウントを使用してクラスター内に物を作成しません。
kubectl get sa
秘密の年齢
デフォルト1 1d
必要に応じて、serviceccountsを追加できます。各ポッドは正確に1つのserviceAccountに関連付けられていますが、複数のポッドは同じserviceaccountを使用できます。
ポッドは同じ名前空間のサービスアカウントのみを使用できます。
ポッドマニフェストでアカウントの名前を指定することにより、サービスアカウントをポッドに割り当てることができます。明示的に割り当てない場合、ポッドはネームスペースのデフォルトのサービスアカウントを使用します
ServiceAccountの既定のアクセス許可では、リソースを一覧表示または変更できません。デフォルトのサービスアカウントでは、クラスターの状態を表示することはできません。
既定では、名前空間の既定のserviceAccountには、認証されていないユーザーの権限以外の権限はありません。
したがって、ポッドはデフォルトでクラスター状態を表示することさえできません。それを行うための適切な許可を彼らに与えるのはあなた次第です。
kubectl exec -it test -n foo sh /#curl localhost:8001/api/v1/namespaces/foo/services {"kind": "Status"、
"apiVersion": "v1"、 "metadata":{}、 "status": "Failure"、 "message": "サービスは禁止されています:ユーザー\" system:serviceaccount:foo:default\"は、名前空間\のAPIグループ\"\"のリソース\" services\"をリストできません"foo \" "、" reason ":" Forbidden "、" details ":{" kind ":" services "}、" code ":403
デフォルトのサービスアカウントの上に表示されているように、サービスをリストできません
しかし、以下のような適切なロールとロールバインディングが与えられた場合
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: foo-role
namespace: foo
rules:
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: null
name: test-foo
namespace: foo
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: foo-role
subjects:
- kind: ServiceAccount
name: default
namespace: foo
今、私は復活サービスをリストすることができます
kubectl exec -it test -n foo sh
/ # curl localhost:8001/api/v1/namespaces/foo/services
{
"kind": "ServiceList",
"apiVersion": "v1",
"metadata": {
"selfLink": "/api/v1/namespaces/bar/services",
"resourceVersion": "457324"
},
"items": []
すべてのserviceAccountsにclusteradmin clusterroleを付与することは、すべての人にジョブを実行するために必要な権限のみを付与し、単一の権限を付与するのは最善ではありません。
ポッドごとに特定のserviceAccountを作成し、それをロールバインディングによってカスタマイズされたロールまたはclusterroleに関連付けることをお勧めします
ポッドの1つがポッドを読み取るだけで、もう1つのポッドがそれらを変更する必要がある場合、2つの異なるサービスアカウントを作成し、ポッド仕様でserviceaccountNameプロパティを指定してそれらのポッドにそれらを使用させます
詳細な説明については、以下のリンクを参照してください
確認してもいい
kubectlはserviceaccount.automountServiceAccountTokenを説明し、サービスアカウントを編集します
kubectl edit serviceaccount default -o yaml
apiVersion: v1
automountServiceAccountToken: false
kind: ServiceAccount
metadata:
creationTimestamp: 2018-10-14T08:26:37Z
name: default
namespace: default
resourceVersion: "459688"
selfLink: /api/v1/namespaces/default/serviceaccounts/default
uid: de71e624-cf8a-11e8-abce-0642c77524e8
secrets:
- name: default-token-q66j4
この変更が行われると、以下に示すように、スポーンしたポッドのいずれにもserviceaccountトークンがありません。
kubectl exec tp -it bash
root@tp:/# cd /var/run/secrets/kubernetes.io/serviceaccount
bash: cd: /var/run/secrets/kubernetes.io/serviceaccount: No such file or directory
アプリケーション/デプロイメントは、デプロイメント構成のdefault
フィールドに指定することにより、serviceAccountName
以外のサービスアカウントで実行できます。
私がサービスアカウントまたは他のユーザーができることは、与えられた(バインドされた)ロールによって決まります-roleBindingsまたはclusterRoleBindingsを参照してください。動詞は、ロールのapiGroups
とresources
の定義の下にあるrules
に基づいています。
default
サービスアカウントには、デフォルトではロールが与えられていないようです。 #2 here で説明されているように、default
サービスアカウントにロールを付与することができます。
this 、「...バージョン1.6以降では、サービスアカウントにautomountServiceAccountToken: false
を設定することで、サービスアカウントのAPI資格情報の自動マウントをオプトアウトできます。
HTH