We are bringing the best of Tectonic to Red Hat OpenShift to build the most secure, hybrid Kubernetes application platform.
Service accounts are API credentials stored in Kubernetes APIs and mounted onto pods as files, providing access-controlled identity to the services running on pods. In effect, any process running inside a pod uses service account to authenticate itself to Kubernetes APIs from within a cluster. For example, when an ingress controller running in cluster needs to read ingress resources, it loads service account secrets mounted into the pod at known locations to authenticate with the API server. The apps running on the clusters use the service accounts secrets as a bearer token. Kubernetes automatically creates a default
service account with relatively limited access in every namespace. If pods don't explicitly request a service account, they are assigned to this default
one. However, creating an additional service account is permitted.
Every service account has an associated username that can be granted RBAC roles, just like a regular user has. Service accounts are tied to namespaces and therefore their username is derived from its namespace and name: system:serviceaccount:<namespace>:<name>
. Because RBAC denies all requests unless explicitly allowed, service accounts, and the pods that use them, must be granted access through RBAC rules.
To create a service account use kubectl create
command or Tectonic Console.
Access rights are granted to a service account associated with a role by using a Role Binding. Do either of the following in Tectonic Console:
admin
.Grant access rights to a service account by associating an appropriate Cluster Role with a Cluster Role Binding. Cluster Role Binding grants permissions to service accounts in all namespaces across the entire cluster. namespace
is omitted from the configuration because Cluster Roles are not namespaced.
Select a Role Name from the drop-down.
If you have navigated from the Roles page, the name of the selected Role will be displayed. For information on Roles, see Default Roles in Tectonic.
In this example, a Cluster Role Binding, example-etcd-operator
is created for the etcd-operator
role. This role has access to non-namespaced third party resources. To verify, go to the Roles page, click etcd-operator
, then select Role Bindings. If creating this Cluster Role Binding is successful, example-etcd-operator
will be listed under the Role Bindings associated with the etcd-operator
role.
To assign a namespace service account, use one of the default Cluster or Namespace Roles, or create a new role for the selected Namespace. Bind the role to an appropriate Role Binding.
While a Cluster Role can be bound down the hierarchy to a Namespace Role Binding, a Namespace Role can't be promoted up the hierarchy to be bound to a Cluster Role Binding.
Select a Role Name from the drop-down.
If you have navigated from the Roles page, name of the selected Role will be displayed, as given in the image below. For information on Roles, see Default Roles in Tectonic.
In this example, a Namespace Role Binding, default-ingress-rolebinding
is created for the ingress-service-account
role that has read access over the ingress resources in the default
namespace. To verify, go to the Roles page, click pod-reader
, then select Role Bindings. If creating this Role Binding is successful, default-ingress-rolebinding
will be listed under the Role Bindings associated with the ingress-service-account
role.
In this example, a Cluster Role Binding, etcd-rolebinding
is created for the etcd-operator
role by using kubectl
command. This role will have read access over the ingress resources in the tectonic-system
namespace.
Define a Role, etcd-operator.yaml
:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: etcd-operator
rules:
- apiGroups:
- etcd.coreos.com
resources:
- clusters
verbs:
- "*"
- apiGroups:
- extensions
resources:
- thirdpartyresources
verbs:
- "*"
- apiGroups:
- storage.k8s.io
resources:
- storageclasses
verbs:
- "*"
- apiGroups:
- ""
resources:
- pods
- services
- endpoints
- persistentvolumeclaims
- events
verbs:
- "*"
- apiGroups:
- apps
resources:
- deployments
verbs:
- "*"
Define a Cluster Role Binding, etcdoperator.yaml
, which gives administrative privileges to the service account within the tectonic-system
namespace:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: example-etcd-operator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- kind: ServiceAccount
name: example etcd operator
namespace: tectonic-system
Run the following command:
kubectl create -f serviceaccount etcdoperator.yaml
If creating the service account is successful, the following message is displayed:
serviceaccount "example-etcd-operator" created
Verify once again by fetching the service accounts:
kubectl get serviceaccounts
Locate example-etcd-operator
in the list of service accounts:
NAME SECRETS AGE
default 1 1d
example-etcd-operator 1 5m
.....
It's recommended to give each application its own service account and not rely on the default service account. The newly created service account can be mounted onto the pod by specifying the service account name in the pod spec. For example:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
k8s-app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
serviceAccountName: public-ingress # note down the name of the service account for future reference