Kubernetes/Security and RBAC - Revision history

Pio2pio: /* ServiceAccount */

2021-12-21T12:41:48Z

ServiceAccount

← Older revision		Revision as of 14:41, 21 December 2021
Line 139:		Line 139:

	Assign ServiceAccount to a pod		Assign ServiceAccount to a pod
	<syntaxhighlightjs ~~lnag~~=yaml>		<syntaxhighlightjs lang=yaml>
	apiVersion: v1		apiVersion: v1
	kind: Pod		kind: Pod

Pio2pio: /* Create a role (namespaced permissions) */

2021-12-21T12:40:14Z

Create a role (namespaced permissions)

← Older revision		Revision as of 14:40, 21 December 2021
Line 199:		Line 199:
	name: service-reader		name: service-reader
	rules:		rules:
	- apiGroups: [""]		- apiGroups: [""] # "" indicates the core API group
	verbs: ["get", "list"]		verbs: ["get", "list"]
	resources: ["services"]		resources: ["services"]
	</source>		</source>


			{{Note\| [https://kubernetes.io/docs/reference/using-api/#api-groups The core (also called legacy) group] indicated by <code>apiGroups: [""]</code> is found at REST path /api/v1. The core group is not specified as part of the apiVersion field, for example, apiVersion: v1.}}

Pio2pio: Pio2pio moved page Kubernetes/Security to Kubernetes/Security and RBAC without leaving a redirect

2021-12-21T12:35:35Z

Pio2pio moved page Kubernetes/Security to Kubernetes/Security and RBAC without leaving a redirect

← Older revision	Revision as of 14:35, 21 December 2021
(No difference)

Pio2pio: /* API Server and Role Base Access Control */

2020-07-12T17:11:41Z

API Server and Role Base Access Control

← Older revision		Revision as of 19:11, 12 July 2020
Line 1:		Line 1:
	= API Server and Role Base Access Control =		= API Server and Role Base Access Control =
			[[AWS/IAM_Policy#AWS_policies.2C_in_my_own_words..]] RBAC terminology

	Once the API server has determined who you are (whether a pod or a user), the authorization is handled by RBAC.		Once the API server has determined who you are (whether a pod or a user), the authorization is handled by RBAC.

Pio2pio: /* Pod Security Policy */

2019-12-11T16:41:29Z

Pod Security Policy

← Older revision		Revision as of 18:41, 11 December 2019
Line 1,134:		Line 1,134:
	= [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy Pod Security Policy] =		= [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy Pod Security Policy] =
	The Kubernetes pod security policy admission controller validates pod creation and update requests against a set of rules. You should have your policies applied to your cluster before enabling the admission controller otherwise no pods will be able to be scheduled.		The Kubernetes pod security policy admission controller validates pod creation and update requests against a set of rules. You should have your policies applied to your cluster before enabling the admission controller otherwise no pods will be able to be scheduled.


			Read more about [https://docs.aws.amazon.com/eks/latest/userguide/pod-security-policy.html AWS EKS psp]

Pio2pio: /* User accounts vs service accounts */

2019-12-11T16:40:42Z

User accounts vs service accounts

← Older revision		Revision as of 18:40, 11 December 2019
Line 75:		Line 75:
	*Auditing considerations for humans and service accounts may differ.		*Auditing considerations for humans and service accounts may differ.
	*A config bundle for a complex system may include a definition of various service accounts for components of that system. Because service accounts can be created ad-hoc and have namespaced names, such config is portable		*A config bundle for a complex system may include a definition of various service accounts for components of that system. Because service accounts can be created ad-hoc and have namespaced names, such config is portable

			= [https://stackoverflow.com/questions/42170380/how-to-add-users-to-kubernetes-kubectl Users] =
			Normal users are assumed to be managed by an outside, independent service. An admin distributing private keys, a user store like Keystone or Google Accounts, even a file with a list of usernames and passwords. In this regard, Kubernetes does not have objects which represent normal user accounts. Regular users cannot be added to a cluster through an API call [https://kubernetes.io/docs/admin/authentication/#users-in-kubernetes read more...]

	= ServiceAccount =		= ServiceAccount =

Pio2pio: /* ServiceAccount */

2019-12-11T16:34:12Z

ServiceAccount

← Older revision		Revision as of 18:34, 11 December 2019
Line 66:		Line 66:
	kubectl get secrets default-token-qqzc7 -o yaml #display secrets		kubectl get secrets default-token-qqzc7 -o yaml #display secrets
	</source>		</source>

			= [https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#user-accounts-vs-service-accounts User accounts vs service accounts] =
			Kubernetes distinguishes between the concept of a user account and a service account for a number of reasons:

			*User accounts are for humans. Service accounts are for processes, which run in pods.
			*User accounts are intended to be global. Names must be unique across all namespaces of a cluster, future user resource will not be namespaced. Service accounts are namespaced.
			*Typically, a cluster’s User accounts might be synced from a corporate database, where new user account creation requires special privileges and is tied to complex business processes. Service account creation is intended to be more lightweight, allowing cluster users to create service accounts for specific tasks (i.e. the principle of least privilege).
			*Auditing considerations for humans and service accounts may differ.
			*A config bundle for a complex system may include a definition of various service accounts for components of that system. Because service accounts can be created ad-hoc and have namespaced names, such config is portable

	= ServiceAccount =		= ServiceAccount =

Pio2pio: /* Resources */

2019-12-11T16:32:36Z

Resources

← Older revision		Revision as of 18:32, 11 December 2019
Line 1,119:		Line 1,119:

	* [https://kubernetes.io/docs/concepts/configuration/secret/ Secrets] K8s docs		* [https://kubernetes.io/docs/concepts/configuration/secret/ Secrets] K8s docs

			= [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy Pod Security Policy] =
			The Kubernetes pod security policy admission controller validates pod creation and update requests against a set of rules. You should have your policies applied to your cluster before enabling the admission controller otherwise no pods will be able to be scheduled.


			Commands tested under
			<source lang=bash>
			$ kubectl version --short
			Client Version: v1.15.0
			Server Version: v1.14.8-eks-b8860f
			</source>


			Default PSP policy in EKS
			<source lang=yaml>
			kubectl get psp eks.privileged -oyaml --export=true #
			Flag --export has been deprecated, This flag is deprecated and will be removed in future.
			apiVersion: extensions/v1beta1
			kind: PodSecurityPolicy
			metadata:
			annotations:
			kubectl.kubernetes.io/last-applied-configuration: \|
			{"apiVersion":"policy/v1beta1","kind":"PodSecurityPolicy","metadata":{"annotations":{"kubernetes.io/description":"privileged allows full unrestricted access to pod features, as if the PodSecurityPolicy controller was not enabled.","seccomp.security.alpha.kubernetes.io/allowedProfileNames":""},"labels":{"eks.amazonaws.com/component":"pod-security-policy","kubernetes.io/cluster-service":"true"},"name":"eks.privileged"},"spec":{"allowPrivilegeEscalation":true,"allowedCapabilities":[""],"fsGroup":{"rule":"RunAsAny"},"hostIPC":true,"hostNetwork":true,"hostPID":true,"hostPorts":[{"max":65535,"min":0}],"privileged":true,"readOnlyRootFilesystem":false,"runAsUser":{"rule":"RunAsAny"},"seLinux":{"rule":"RunAsAny"},"supplementalGroups":{"rule":"RunAsAny"},"volumes":["*"]}}
			kubernetes.io/description: privileged allows full unrestricted access to pod features,
			as if the PodSecurityPolicy controller was not enabled.
			seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
			creationTimestamp: null
			labels:
			eks.amazonaws.com/component: pod-security-policy
			kubernetes.io/cluster-service: "true"
			name: eks.privileged
			selfLink: /apis/extensions/v1beta1/podsecuritypolicies/eks.privileged
			spec:
			allowPrivilegeEscalation: true
			allowedCapabilities:
			- '*'
			fsGroup:
			rule: RunAsAny
			hostIPC: true
			hostNetwork: true
			hostPID: true
			hostPorts:
			- max: 65535
			min: 0
			privileged: true
			runAsUser:
			rule: RunAsAny
			seLinux:
			rule: RunAsAny
			supplementalGroups:
			rule: RunAsAny
			volumes:
			- '*'
			</source>


			;Verify
			Get available users, groups and serviceaccounts
			<source lang=bash>
			kubectl get serviceaccounts -A
			kubectl get role -A
			kubectl get clusterrole
			</source>


			<code>kubectl</code> allows you to pose as other users using <code>--as</code> to perform operations, but you can also use it to inspect permissions.
			<source lang=bash>
			$ kubectl auth can-i use deployment.apps/coredns
			yes

			# User impersonation syntax: --as=system:serviceaccount:default:default
			# < roleName >:< ns >:<user>
			kubectl auth can-i use psp/eks.privileged --as-group=system:authenticated --as=any-user
			Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'extensions'
			no
			kubectl auth can-i list secrets --namespace dev --as dave

			# drain node (no namespace scope resource)
			kubectl auth can-i drain node/ip-10-35-65-154.eu-west-1.compute.internal --as-group=system:authenticated --as=any-user
			Warning: resource 'nodes' is not namespace scoped
			no
			kubectl auth can-i drain node/ip-10-35-65-154.eu-west-1.compute.internal
			Warning: resource 'nodes' is not namespace scoped
			yes

			# delete a namespace resource
			kubectl auth can-i delete svc/kube-dns -n kube-system
			yes
			kubectl auth can-i delete svc/kube-dns -n kube-system --as-group=system:authenticated --as=any-user
			no
			</source>

	= Resources =		= Resources =

Pio2pio: /* ServiceAccount */

2019-10-21T20:21:53Z

ServiceAccount

← Older revision		Revision as of 22:21, 21 October 2019
Line 140:		Line 140:
	restartPolicy: Always		restartPolicy: Always
	</syntaxhighlightjs>		</syntaxhighlightjs>

			== Resources ==
			*[https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/ Managing Service Accounts]
			*[https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ Configure Service Accounts for Pods]

	= Create Administrative account =		= Create Administrative account =

Pio2pio: /* ServiceAccount */

2019-10-21T20:20:09Z

ServiceAccount

← Older revision		Revision as of 22:20, 21 October 2019
Line 68:		Line 68:

	= ServiceAccount =		= ServiceAccount =
	The API server is first evaluating if the request is coming from a service account or a normal user /or normal user account meeting, a private key, a user store or even a file with a list of user names and passwords. Kubernetes doesn't have objects that represent normal user accounts, and normal users cannot be added to the cluster through.		<code>ServiceAccount</code> allow containers running in pods to access the Kubernetes API. Some applications may need to interact with the k8s cluster itself, and the <code>serviceaccounts</code> allow it to do securely with limited permissions.


			The API server is first evaluating if the request is coming from a <tt>service account</tt> or a <tt>normal user</tt> /or normal user account meeting, a private key, a user store or even a file with a list of user names and passwords. Kubernetes doesn't have objects that represent normal user accounts, and normal users cannot be added to the cluster through.


			Create a ServiceAccount
	<source lang=bash>		<source lang=bash>
	kubectl get ~~serviceaccounts~~ #or 'sa' in short		kubectl get serviceaccount # 'sa' in short
	kubectl create serviceaccount jenkins		kubectl create serviceaccount jenkins -oyaml --save-config --dry-run
			kubectl get serviceaccount jenkins -oyaml
	kubectl get ~~serviceaccounts~~ jenkins -o yaml		</source>
			<syntaxhighlightjs lang=yaml>
	apiVersion: v1		apiVersion: v1
	kind: ServiceAccount		kind: ServiceAccount
Line 85:		Line 92:
	secrets:		secrets:
	- name: jenkins-token-cspjm		- name: jenkins-token-cspjm
			</syntaxhighlightjs>


	kubectl get secret ~~[secret_name]~~		Read ServiceAccount certificate and token
			<source lang=bash>
			kubectl get secret jenkins-token-cspjm
			NAME TYPE DATA AGE
			jenkins-token-cspjm kubernetes.io/service-account-token 3 73s

			kubectl get secrets jenkins-token-s875g -oyaml
	</source>		</source>
			<syntaxhighlightjs lang=yaml>
			apiVersion: v1
			data: # all data is base64 encoded
			ca.crt: LS0tLS1CR******UtLS0tLQo=
			namespace: c2VjcmV0cw==
			token: ZXlKaGJHY2******1RmN0VlcktRWEdQbVkyWVpxYnc=
			kind: Secret
			metadata:
			annotations:
			kubernetes.io/service-account.name: jenkins
			kubernetes.io/service-account.uid: 49f48d04-f43d-11e9-8421-0a39c67f4f42
			creationTimestamp: "2019-10-21T19:59:28Z"
			name: jenkins-token-cspjm # the secret name
			namespace: default
			resourceVersion: "189166"
			selfLink: /api/v1/namespaces/secrets/secrets/jenkins-token-cspjm
			uid: 49f6ea57-f43d-11e9-8421-0a39c67f4f42
			type: kubernetes.io/service-account-token
			</syntaxhighlightjs>


	Assign ~~ServiceAccoubt~~ to a pod		Assign ServiceAccount to a pod
	<~~source~~ lnag=yaml>		<syntaxhighlightjs lnag=yaml>
	apiVersion: v1		apiVersion: v1
	kind: Pod		kind: Pod
	metadata:		metadata:
	name: busybox		name: busybox
	~~namespace: default~~
	spec:		spec:
	serviceAccountName: jenkins #<-- ServiceAccount		serviceAccountName: jenkins # <- ServiceAccount
	containers:		containers:
	- image: busybox:~~1.28.4~~		- image : busybox-serviceaccount
	command:		name : busybox
	- sleep		command: ["/bin/sleep"
	- "3600"		args : ["3600"]
	imagePullPolicy: IfNotPresent		imagePullPolicy: IfNotPresent
	~~name: busybox~~
	restartPolicy: Always		restartPolicy: Always
			</syntaxhighlightjs>

	~~#Verify~~
	~~kubectl.exe get pods -o yaml \| sls serviceAccount~~

	~~{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"busybox","namespace":"default"},"spec":{"c~~
	~~ontainers":[{"command":["sleep","3600"],"image":"busybox:1.28.4","imagePullPolicy":"IfNotPresent","name":"busybox"}],"r~~
	~~estartPolicy":"Always","serviceAccountName":"jenkins"}}~~
	~~- mountPath: /var/run/secrets/kubernetes.io/serviceaccount~~
	~~serviceAccount: jenkins~~
	~~serviceAccountName: jenkins~~
	~~</source>~~
	= Create Administrative account =		= Create Administrative account =
	This is a process of setting up a new remote administrator.		This is a process of setting up a new remote administrator.