{"id":2148,"date":"2022-02-16T10:06:27","date_gmt":"2022-02-16T10:06:27","guid":{"rendered":"https:\/\/blog.samarthya.me\/wps\/?p=2148"},"modified":"2022-02-21T04:35:41","modified_gmt":"2022-02-21T04:35:41","slug":"serviceaccount","status":"publish","type":"post","link":"https:\/\/blog.samarthya.me\/wps\/2022\/02\/16\/serviceaccount\/","title":{"rendered":"ServiceAccount"},"content":{"rendered":"\n<p>If you have seen errors like these when deploying using a <code>serviceAccount<\/code><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: could not get information about the resource ConfigMap \"spinnaker-hellow-pipline\" in namespace \"spinnaker\": configmaps \"spinnaker-hellow-pipline\" is forbidden: User \"system:serviceaccount:jenkins:default\" cannot get resource \"configmaps\" in API group \"\" in the namespace \"spinnaker\"<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"what\">What?<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li>A service account provides an identity for processes that run in a Pod.<\/li><li>Every namespace has a default <code>service account<\/code><\/li><li>When you create a pod, if you do not specify a service account, it is automatically assigned the <code>default<\/code> service account in the same namespace.<\/li><li>To use a non-default service account, set the <code>spec.serviceAccountName<\/code> field of a pod to the name of the service account you wish to use.<\/li><li>The service account has to exist at the time the pod is created, or it will be rejected.<\/li><li>The service account of an already created pod cannot be updated<\/li><\/ul>\n\n\n\n<figure class=\"wp-block-pullquote has-border-color has-pale-cyan-blue-border-color has-black-color has-pale-cyan-blue-background-color has-text-color has-background\"><blockquote><p>Default RBAC policies grant scoped permissions to control-plane components, <code>nodes<\/code>, and <code>controllers<\/code>, but grant <em>no permissions<\/em> to service accounts outside the <code>kube-system<\/code> namespace (beyond discovery permissions given to all authenticated users).<\/p><cite>Official documentation<\/cite><\/blockquote><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"example\">Example<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>apiVersion: v1\nkind: ServiceAccount\nmetadata:\n  creationTimestamp: \"2021-08-27T07:52:20Z\"\n  name: default\n  namespace: default\n  resourceVersion: \"XXXX\"\n  uid: XXXX\nsecrets:\n- name: default-token-vcb75<\/code><\/pre>\n\n\n\n<p>Let&#8217;s add docker-registry secret to the <code>SA<\/code>. (My secret name is samarthya-docker)<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl patch serviceaccount default -p '{\"imagePullSecrets\": &#91;{\"name\": \"samarthya-docker\"}]}'<\/code><\/pre>\n\n\n\n<p>The updated <code>SA<\/code><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>apiVersion: v1\nimagePullSecrets:\n- name: samarthya-docker\nkind: ServiceAccount\nmetadata:\n  creationTimestamp: \"2021-08-27T07:52:20Z\"\n  name: default\n  namespace: default\n  resourceVersion: \"XXXX\"\n  uid: XXXXX\nsecrets:\n- name: default-token-vcb75<\/code><\/pre>\n\n\n\n<p>This helps you ensure you do not get image pull errors as it will be using the secret docker-registry to pull any missing images.<\/p>\n\n\n\n<figure class=\"wp-block-pullquote has-white-color has-black-background-color has-text-color has-background\"><blockquote><p>Every <code>namespace<\/code> has a <code>default<\/code> <code>serviceaccount<\/code><\/p><\/blockquote><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"e-g-namespace-jenkins\">e.g <code>namespace jenkins<\/code><\/h4>\n\n\n\n<pre class=\"wp-block-code\"><code>k get sa default -n jenkins -oyaml<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>apiVersion: v1\nkind: ServiceAccount\nmetadata:\n  creationTimestamp: \"2022-02-02T10:20:58Z\"\n  name: default\n  namespace: jenkins\n  resourceVersion: \"25024083\"\n  uid: 53faa1fb-b30c-4159-94f8-64cee3f63629\nsecrets:\n- name: default-token-lhbgn<\/code><\/pre>\n\n\n\n<p>Managing access controls for the <code>SA<\/code> created needs roles and role binding<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"example-1\">Example<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>kubectl create rolebinding my-sa-view \\\n  --clusterrole=view \\\n  --serviceaccount=my-namespace:my-sa \\\n  --namespace=my-namespace<\/code><\/pre>\n\n\n\n<p>Listing all the clusterroles<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>k get clusterroles --show-kind=true<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>> k get rolebinding -n jenkins\nNAME                         ROLE                             AGE\njenkins-admin-binding        ClusterRole\/admin                6d22h\nmyjenkins-schedule-agents    Role\/myjenkins-schedule-agents   13d\nmyjenkins-watch-configmaps   Role\/myjenkins-casc-reload       13d<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\"><li>Fine-grained role bindings provide greater security.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"help\">Help<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li><a href=\"https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/service-accounts-admin\/\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/service-accounts-admin\/<\/a><\/li><li><a href=\"https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/rbac\/\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/rbac\/<\/a><\/li><\/ul>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>If you have seen errors like these when deploying using a serviceAccount What? A service account provides an identity for processes that run in a Pod. Every namespace has a default service account When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":16,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"image","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[195,34],"tags":[243,210,244],"class_list":["post-2148","post","type-post","status-publish","format-image","has-post-thumbnail","hentry","category-kubernetes","category-technical","tag-kubernetes","tag-rbac","tag-serviceaccount","post_format-post-format-image"],"_links":{"self":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2148","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/comments?post=2148"}],"version-history":[{"count":0,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/posts\/2148\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media\/16"}],"wp:attachment":[{"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/media?parent=2148"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/categories?post=2148"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.samarthya.me\/wps\/wp-json\/wp\/v2\/tags?post=2148"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}