Using Kubernetes Engine

• 1: Authentication and Authorization
• 2: Accessing the Cluster
• 3: type LoadBalancer Service Usage
• 4: Considerations for Use
• 5:

1 - Authentication and Authorization

Kubernetes Engine has Kubernetes’ authentication and RBAC authorization features applied. This explains the authentication and authorization features of Kubernetes and how to link them with Kubernetes Engine and IAM.

Kubernetes Authentication and Authorization

This explains the authentication and RBAC authorization features of Kubernetes.

Authentication

The Kubernetes API server acquires the necessary information for user or account authentication from certificates or authentication tokens and proceeds with the authentication process.

Authorization

The Kubernetes API server checks if the user has permission for the requested action using the user information obtained through the authentication process and the RBAC-related objects. There are four types of RBAC-related objects as follows:

Role

Kubernetes has several predefined ClusterRoles. Some of these ClusterRoles do not have the prefix system:, which means they are intended for user use. These include the cluster-admin role that can be applied to the entire cluster using ClusterRoleBinding, and the admin, edit, and view roles that can be applied to a specific namespace using RoleBinding.

In addition to the predefined ClusterRoles, you can define separate roles (or ClusterRoles) as needed. For example:

# Role that grants permission to view pods in the "default" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# Role that grants permission to view pods in the "default" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# ClusterRole that grants permission to view nodes
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

# ClusterRole that grants permission to view nodes
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Role Binding

To manage access to the Kubernetes Engine using Samsung Cloud Platform IAM, you need to understand the relationship between Kubernetes’ role binding and IAM. The target (subjects) of role binding (or cluster role binding) can include individual users (User) or groups (Group).

• User matches the Samsung Cloud Platform username, and Group matches the IAM user group name.

For role binding/cluster role binding, subjects.kind can be one of the following:

• User: Binds to a Samsung Cloud Platform individual user.
• Group: Binds to a Samsung Cloud Platform IAM user group.

The subjects.name of role binding/cluster role binding can be specified as follows:

• User case: Samsung Cloud Platform individual username (e.g. jane.doe)
• Group case: Samsung Cloud Platform IAM user group name (e.g. ReadPodsGroup)

In this way, an IAM user group is bound to a role binding (or cluster role binding) written in the Kubernetes Engine cluster. Additionally, the permission to perform API operations included in the role (or cluster role) bound to the group is granted.

Example) Role Binding read-pods #1

An example of writing a User (Samsung Cloud Platform individual user) to a role binding is as follows:

# This role binding allows the user "jane.doe@example.com" to view pods in the "default" namespace.
# A "pod-reader" role must exist in the namespace.
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
roleRef:
  # "roleRef" specifies the binding to a role or cluster role.
  kind: Role       # Must be Role or ClusterRole.
  name: pod-reader # Must match the name of the role or cluster role to bind.
  apiGroup: rbac.authorization.k8s.io
subjects:
# One or more "targets" can be specified.
- kind: User
  name: jane.doe
  apiGroup: rbac.authorization.k8s.io

# This role binding allows the user "jane.doe@example.com" to view pods in the "default" namespace.
# A "pod-reader" role must exist in the namespace.
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
roleRef:
  # "roleRef" specifies the binding to a role or cluster role.
  kind: Role       # Must be Role or ClusterRole.
  name: pod-reader # Must match the name of the role or cluster role to bind.
  apiGroup: rbac.authorization.k8s.io
subjects:
# One or more "targets" can be specified.
- kind: User
  name: jane.doe
  apiGroup: rbac.authorization.k8s.io

If a role binding like the above is created in a cluster, a user with the username jane.doe is granted the permission to perform the API actions defined in the pod-reader role.

Example) Role Binding read-pods #2

An example of writing a group (IAM user group) to a role binding is as follows:

# This role binding allows users in the "ReadPodsGroup" group to view pods in the "default" namespace.
# A "pod-reader" role must exist in the namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
# One or more "targets" can be specified.
- kind: Group
  name: ReadPodsGroup
  apiGroup: rbac.authorization.k8s.io

# This role binding allows users in the "ReadPodsGroup" group to view pods in the "default" namespace.
# A "pod-reader" role must exist in the namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
# One or more "targets" can be specified.
- kind: Group
  name: ReadPodsGroup
  apiGroup: rbac.authorization.k8s.io

If a role binding like the above is created in the cluster, users in the IAM user group ReadPodsGroup are granted the permission to perform API operations written in the pod-reader role.

Example) Cluster Role Binding read-nodes

# This cluster role binding allows users in the "ReadNodesGroup" group to view nodes.
# A cluster role named "node-reader" must exist.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ReadNodesGroup
  apiGroup: rbac.authorization.k8s.io

# This cluster role binding allows users in the "ReadNodesGroup" group to view nodes.
# A cluster role named "node-reader" must exist.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ReadNodesGroup
  apiGroup: rbac.authorization.k8s.io

When a cluster role binding like the one above is created in the cluster, users in the IAM user group ReadNodesGroup are granted the permissions to perform the API actions written in the cluster role node-reader.

Predefined Roles and Role Bindings for Samsung Cloud Platform

The Kubernetes Engine of Samsung Cloud Platform has predefined cluster role bindings scp-cluster-admin, scp-view, scp-namespace-view, and cluster roles scp-namespace-view. The following table shows the binding relationship between predefined roles and role bindings, and Samsung Cloud Platform users. Here, cluster roles cluster-admin and view are predefined within the Kubernetes cluster. For more detailed explanations, refer to the Roles section.

• According to the cluster role binding scp-cluster-admin, users in the IAM user groups AdministratorGroup or OperatorGroup, as well as the Kubernetes Engine product applicant, are granted cluster administrator permissions.
• According to the cluster role binding scp-view, users in the ViewerGroup are granted cluster viewer permissions. More precisely, since it is linked to the predefined cluster role view in Kubernetes, access permissions for cluster-scoped resources (e.g., namespaces, nodes, ingress classes, etc.) and secrets within namespaces are not included. For more detailed explanations, refer to the Roles section.
• According to the cluster role binding scp-namespace-view, all authenticated users in the cluster are granted namespace viewer permissions.

The details of predefined roles and role bindings for Samsung Cloud Platform are as follows:

Cluster Role Binding scp-cluster-admin

The cluster role binding scp-cluster-admin is bound to the cluster role cluster-admin and bound to the IAM user groups AdministratorGroup, OperatorGroup, and the SCP user (Kubernetes Engine cluster creator) according to the subjects.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
  name: scp-cluster-admin
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: AdministratorGroup
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: OperatorGroup
  apiGroup: rbac.authorization.k8s.io
- kind: User                 # Cluster creator
  name: jane.doe # cluster creater name
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
  name: scp-cluster-admin
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: AdministratorGroup
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: OperatorGroup
  apiGroup: rbac.authorization.k8s.io
- kind: User                 # Cluster creator
  name: jane.doe # cluster creater name
  apiGroup: rbac.authorization.k8s.io

Cluster Role Binding scp-view

The cluster role binding scp-view is bound to the cluster role view and bound to the IAM user group ViewerGroup according to the subjects.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-view
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ViewerGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-view
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ViewerGroup
  apiGroup: rbac.authorization.k8s.io

Cluster Role and Cluster Role Binding scp-namespace-view

Cluster Role scp-namespace-view is a role that defines the authority to view namespaces. Cluster Role Binding scp-namespace-view is associated with Cluster Role scp-namespace-view and grants namespace view authority to all authenticated users in the cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scp-namespace-view
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-namespace-view
roleRef:
  kind: ClusterRole
  name: scp-namespace-view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scp-namespace-view
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-namespace-view
roleRef:
  kind: ClusterRole
  name: scp-namespace-view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

IAM User Group RBAC Use Case

This chapter explains examples of granting authority by major user scenarios. The names of IAM user groups, ClusterRoleBindings/RoleBindings, and ClusterRoles presented here are examples for understanding. Administrators should define and apply appropriate names and authorities according to their needs.

Cluster Administrator

To create a cluster administrator, follow these steps:

1. Create an IAM user group named ClusterAdminGroup.
2. Create a ClusterRoleBinding with the following content in the target cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-group
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ClusterAdminGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-group
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ClusterAdminGroup
  apiGroup: rbac.authorization.k8s.io

• It is associated with the default ClusterRole cluster-admin, granting administrator authority for the cluster.

Cluster Editor

To create a cluster editor, follow these steps:

1. Create an IAM user group named ClusterEditGroup.
2. Create a ClusterRoleBinding with the following content in the target cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-edit-group
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ClusterEditGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-edit-group
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ClusterEditGroup
  apiGroup: rbac.authorization.k8s.io

• The default cluster role edit is associated with it, and editor permissions are granted for the cluster.

Cluster Viewer

To create a cluster viewer, follow these steps:

1. Create an IAM user group named ClusterViewGroup.
2. Create a cluster role binding with the following content in the target cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-view-group
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ClusterViewGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-view-group
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ClusterViewGroup
  apiGroup: rbac.authorization.k8s.io

• The default cluster role view is associated with it, and viewer permissions are granted for the cluster.

Namespace Administrator

To create a namespace administrator, follow these steps:

1. Create an IAM user group named NamespaceAdminGroup.
2. Create a role binding with the following content in the target cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceAdminGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceAdminGroup
  apiGroup: rbac.authorization.k8s.io

• The default cluster role admin is associated with it, and administrator permissions are granted for the namespace.

Namespace Editor

To create a namespace editor, follow these steps:

1. Create an IAM user group named NamespaceEditGroup.
2. Create a role binding with the following content in the target cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-edit-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceEditGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-edit-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceEditGroup
  apiGroup: rbac.authorization.k8s.io

• The default cluster role edit is associated with it, and editor permissions are granted for the namespace.

Namespace Viewer

To create a namespace viewer, follow these steps:

1. Create an IAM user group named NamespaceViewGroup.
2. Create a role binding with the following content in the target cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-view-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceViewGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-view-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceViewGroup
  apiGroup: rbac.authorization.k8s.io

• The default cluster role view is associated with it, and viewer permissions are granted for the namespace. To create a namespace viewer, follow these steps:

1. Create an IAM user group: Create an IAM user group named NamespaceViewGroup.
2. Create a role binding: Create a role binding with the following content in the target cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-view-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceViewGroup
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-view-group
  namespace: <namespace_name>
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: NamespaceViewGroup
  apiGroup: rbac.authorization.k8s.io

• The view cluster role is associated with the viewer permission for the specified namespace.

Practice Example

This chapter describes an example and procedure for applying an administrator to a specific namespace.

• IAM user group: NamespaceAdminGroup
• IAM policy: NamespaceAdminAccess
• Role binding: namespace-admin-group

Create an IAM User Group

To create an IAM user group in Samsung Cloud Platform, follow these steps:

1. Click All Services > Management > IAM. The Identity and Access Management (IAM) Service Home page appears.

2. On the Service Home page, click User Group. The User Group List page appears.

3. On the User Group List page, click Create User Group.

   • Enter the required information in the Basic Information, Add User, Attach Policy, and Additional Information sections.

     Category	Required	Description
     User Group Name	Required	Enter the user group name Use Korean, English, numbers, and special characters (+=,.@-_) to enter a value between 3 and 24 characters Enter NamespaceAdminGroup as the user group name
     Description	Optional	Description of the user group name Enter a detailed description of the user group name, up to 1,000 characters
     User	Optional	Users to add to the user group The list of users registered in the account is displayed, and the selected user’s name is displayed at the top of the screen when the checkbox is selected Click the Delete button at the top of the screen or uncheck the checkbox in the user list to cancel the selection of the selected user If there are no users to add, click Create User at the bottom of the user list to register a new user, and then refresh the user list to select the user
     Policy	Optional	Policy to attach to the user group The list of policies registered in the account is displayed, and the selected policy name is displayed at the top of the screen when the checkbox is selected Select ViewerAccess in the policy list
     Tag	Optional	Tags to add to the user group Up to 50 tags can be added per resource

     Table. User Group Creation Information Input Items

4. Click the Complete button. The User Group List page appears.

Create an IAM Policy

To create an IAM policy in Samsung Cloud Platform, follow these steps:

1. Click All Services > Management > IAM. The Identity and Access Management (IAM) Service Home page appears.

2. On the Service Home page, click Policy. The Policy List page appears.

3. On the Policy List page, click Create Policy. The Create Policy page appears.

4. Enter the required information in the Basic Information and Additional Information sections.

   Category	Required	Description
   Policy Name	Required	Enter the policy name Use Korean, English, numbers, and special characters (+=,.@-_) to enter a value between 3 and 128 characters Enter NamespaceAdminAccess as the policy name
   Description	Optional	Description of the policy name Enter a detailed description of the policy name, up to 1,000 characters
   Tag	Optional	Tags to add to the policy Up to 50 tags can be added per resource

   Table. Policy Creation Information Input Items - Basic Information and Additional Information

5. Click the Next button. The Permission Settings section appears.

6. Enter the required information in the Permission Settings section.

   • Select Kubernetes Engine in the Service section.

   • You can create a policy by importing an existing policy using Policy Import. For more information about Policy Import, see Policy Import.

     Category	Required	Description
     Control Type	Required	Select the policy control type Allow Policy: A policy that allows defined permissions Deny Policy: A policy that denies defined permissions The deny policy takes precedence for the same target
     Action	Required	Select actions provided by each service Create: CreateKubernetesObject selected Delete: DeleteKubernetesObject selected List: ListKubernetesEngine, ListKubernetesObject selected Read: DetailKubernetesObject selected Update: UpdateKubernetesObject selected Add Action Directly: Use wildcard * to specify multiple actions at once
     Applied Resource	Required	Resource to which the action is applied All Resources: Apply to all resources for the selected action Individual Resource: Apply only to the specified resource for the selected action Individual resources are only possible when selecting actions that allow individual resource selection (purple actions) Click the Add Resource button to specify the target resource by resource type For more information on Add Resource, see Registering individual resources as applied resources
     Authentication Type	Required	Authentication method for the target user All Authentication: Apply regardless of authentication method API Key Authentication: Apply to users who use API key authentication IAM Key Authentication, Console Login: Apply to users who use IAM key authentication or console login
     Applied IP	Required	IP addresses to which the policy is applied User-specified IP: Register and manage IP addresses directly by the user Applied IP: Register IP addresses directly by the user as IP addresses or ranges to which the policy is applied Excluded IP: Register IP addresses to be excluded from Applied IP as IP addresses or ranges All IP: Do not restrict IP access Allow access to all IP addresses, but if exceptions are needed, register Excluded IP to restrict access to registered IP addresses

     Table. Policy creation information input items - Permission settings

7. Click the Next button. Move to the Input Information Check page.
8. Check the input information and click the Complete button. Move to the Policy List page.

Add a user to an IAM user group

To add a user to an IAM user group in Samsung Cloud Platform, follow these steps.

1. Click All Services > Management > IAM menu. Move to the Identity and Access Management (IAM) Service Home page.
2. On the Service Home page, click the User menu. Move to the User List page.
3. On the User List page, click the user to be added to the IAM user group. Move to the User Details page.
4. On the User Details page, click the User Group tab.
5. On the user group tab, select the Add User Group button. Move to the Add User Group page.
6. On the Add User Group page, select the user group to be added and click the Complete button. Move to the User Details page.
   • Select NamespaceAdminGroup from the user group.

Create a role binding

Create a role binding by referring to the example below.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin-group
  namespace: dev # target namespace
roleRef:
  kind: ClusterRole
  name: admin # pre-defined cluster role in Kubernetes
  apiGroup: rbac.authorization.k8s.io
subjects: 
- kind: Group
  name: NamespaceAdminGroup # IAM user group created earlier
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: namespace-admin-group
  namespace: dev # target namespace
roleRef:
  kind: ClusterRole
  name: admin # pre-defined cluster role in Kubernetes
  apiGroup: rbac.authorization.k8s.io
subjects: 
- kind: Group
  name: NamespaceAdminGroup # IAM user group created earlier
  apiGroup: rbac.authorization.k8s.io

Verify the user

Verify that the user’s namespace permissions are applied normally.

To verify namespace user permissions in Samsung Cloud Platform, follow these steps.

1. Click All Services > Container > Kubernetes Engine menu. Move to the Kubernetes Engine Service Home page.
2. On the Service Home page, click Workload menu under Pod. Move to the Pod List page.
3. On the Pod List page, select the cluster and namespace from the gear button at the top left and click Confirm.
4. On the Pod List page, verify that the pod list is retrieved.
   • If you select a namespace with permissions, the pod list will be displayed.
   • If you select a namespace without permissions, a confirmation window will be displayed indicating that you do not have permission to retrieve the list.

2 - Accessing the Cluster

kubectl Installation and Usage Guide

After creating a Kubernetes Engine service, you can use the Kubernetes command-line tool kubectl to execute commands on a Kubernetes cluster. Using kubectl, you can deploy applications, inspect and manage cluster resources, and view logs. You can find how to install and use kubectl in the official Kubernetes documentation as follows.

To access a Kubernetes cluster with kubectl, you need a kubeconfig file containing the Kubernetes server address and authentication information.

Kubernetes Engine supports authentication via admin certificate kubeconfig and user authentication key kubeconfig.

admin certificate kubeconfig

This kubeconfig uses the admin certificate as an authentication method when accessing the Kubernetes API.

Admin kubeconfig download

Kubernetes Engine > Cluster List > Cluster Details > Admin kubeconfig Download button to click and download the kubeconfig file.

Admin kubeconfig use

User authentication key kubeconfig

This kubeconfig uses the user’s Open API authentication key as the authentication method when accessing the Kubernetes API.

User kubeconfig download

Kubernetes Engine > Cluster List > Cluster Details > User kubeconfig download Click the button to download the kubeconfig file.

Add authentication key token to user kubeconfig file

Below is an example of a user’s kubeconfig file. To use the kubeconfig file, you need to add the authentication key token (AUTHKEY_TOKEN) information in the token field inside the file.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0t...
    server: https://my-cluster-a1c3e.ske.xxx.samsungsdscloud.com:6443
  name: my-cluster-a1c3e
contexts:
- context:
    cluster: my-cluster-a1c3e
    user: jane.doe
  name: jane.doe@my-cluster-a1c3e
current-context: jane.doe@my-cluster-a1c3e
kind: Config
preferences: {}
users:
- name: jane.doe
  user:
    token: <AUTHKEY_TOKEN> #### writing needed

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0t...
    server: https://my-cluster-a1c3e.ske.xxx.samsungsdscloud.com:6443
  name: my-cluster-a1c3e
contexts:
- context:
    cluster: my-cluster-a1c3e
    user: jane.doe
  name: jane.doe@my-cluster-a1c3e
current-context: jane.doe@my-cluster-a1c3e
kind: Config
preferences: {}
users:
- name: jane.doe
  user:
    token: <AUTHKEY_TOKEN> #### writing needed

AUTHKEY_TOKEN can be generated by concatenating the authentication key’s ACCESS_KEY and SECRET_KEY with a colon (:) and then Base64 encoding it. The following is an example of creating AUTHKEY_TOKEN in a Linux environment.

$ ACCESS_KEY=5df418813aed051548a72f4a814cf09e
$ SECRET_KEY=6ba7b810-9dad-11d1-80b4-00c04fd430c8
$ AUTHKEY_TOKEN=$(echo -n "$ACCESS_KEY:$SECRET_KEY" | base64 -w0)
$ echo $AUTHKEY_TOKEN
NWRmNDE4ODEzYWVkMDUxNTQ4YTcyZjRhODE0Y2YwOWU6NmJhN2I4MTAtOWRhZC0xMWQxLTgwYjQtMDBmMDRmZDQzMGM4r

$ ACCESS_KEY=5df418813aed051548a72f4a814cf09e
$ SECRET_KEY=6ba7b810-9dad-11d1-80b4-00c04fd430c8
$ AUTHKEY_TOKEN=$(echo -n "$ACCESS_KEY:$SECRET_KEY" | base64 -w0)
$ echo $AUTHKEY_TOKEN
NWRmNDE4ODEzYWVkMDUxNTQ4YTcyZjRhODE0Y2YwOWU6NmJhN2I4MTAtOWRhZC0xMWQxLTgwYjQtMDBmMDRmZDQzMGM4r

User kubeconfig execution example

You can see an example of executing the user kubeconfig.

When access is blocked by access control or a firewall

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
Unable to connect to the server: dial tcp 123.123.123.123:6443: i/o timeout

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
Unable to connect to the server: dial tcp 123.123.123.123:6443: i/o timeout

When AUTHKEY_TOKEN does not match and authentication fails

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
error: You must be logged in to the server (Unauthorized)

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
error: You must be logged in to the server (Unauthorized)

AUTHKEY_TOKEN When authentication succeeds

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
...
kube-node-lease    Active 10d
kube-public        Active 10d
kube-system        Active 10d

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
...
kube-node-lease    Active 10d
kube-public        Active 10d
kube-system        Active 10d

AUTHKEY_TOKEN Authentication succeeded but no permission

$ kubectl --kubeconfig=user-kubeconfig.yaml get nodes
Error from server (Forbidden): nodes is forbidden: User "jane.doe" cannot list resource "nodes" in API group "" at the cluster scope

$ kubectl --kubeconfig=user-kubeconfig.yaml get nodes
Error from server (Forbidden): nodes is forbidden: User "jane.doe" cannot list resource "nodes" in API group "" at the cluster scope

3 - type LoadBalancer Service Usage

Service Configuration Method

Service manifest file (example: my-lb-svc.yaml ) can be written and applied to configure a Service of type LoadBalancer.

To create and apply a type LoadBalancer Service, follow the steps below.

1. Service manifest file my-lb-svc.yaml write.

   Sample Code Download

   Copy Code

   Color mode

   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
   spec:
     selector:
       app.kubernetes.io/name: MyApp
     ports:
       - protocol: TCP
         port: 80
         targetPort: 9376
         appProtocol: tcp # Refer to the LB service protocol type setting section
     type: LoadBalancer

   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
   spec:
     selector:
       app.kubernetes.io/name: MyApp
     ports:
       - protocol: TCP
         port: 80
         targetPort: 9376
         appProtocol: tcp # Refer to the LB service protocol type setting section
     type: LoadBalancer

2. Deploy the Service manifest using the kubectl apply command.

   Sample Code Download

   Copy Code

   Color mode

     
   kubectl apply -f my-lb-svc.yaml

     
   kubectl apply -f my-lb-svc.yaml

3. kubectl get service Use the command to check the Load Balancer configuration.
   Sample Code Download

   Copy Code

   Color mode

   # kubectl get service my-lb-svc
   NAMESPACE     NAME         TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)         AGE
   default       my-lb-svc    LoadBalancer   172.20.49.206    123.123.123.123   80:32068/TCP    3m

   # kubectl get service my-lb-svc
   NAMESPACE     NAME         TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)         AGE
   default       my-lb-svc    LoadBalancer   172.20.49.206    123.123.123.123   80:32068/TCP    3m

Protocol Type

You can create a Service manifest and use it. Here is a simple example.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    ...
  ports:
    - port: 80
      targetPort: 9376
      protocol: TCP    # required (choose one of TCP, UDP)
      appProtocol: tcp # choice (if not entered, select one of tcp, http, https)
  type: LoadBalancer   # type LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    ...
  ports:
    - port: 80
      targetPort: 9376
      protocol: TCP    # required (choose one of TCP, UDP)
      appProtocol: tcp # choice (if not entered, select one of tcp, http, https)
  type: LoadBalancer   # type LoadBalancer

The list of protocols (protocol and appProtocol) supported by the type Load Balancer Service in Kubernetes Engine, and the settings applied to the Load Balancer service accordingly, are as follows.

• k8s Service can specify multiple ports for a single service according to the manifest spec.

L4 Service Manifest creation example

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: LoadBalancer

L7 Service Manifest creation example

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-layer-type: "L7" # required
    service.beta.kubernetes.io/scp-load-balancer-client-cert-id: "24da35de187b450eb0cf09fb6fa146de" # required
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - appProtocol: http # required
      protocol: TCP
      port: 80
      targetPort: 9376
    - appProtocol: https # required
      protocol: TCP
      port: 443
      targetPort: 9898
  type: LoadBalancer
  

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-layer-type: "L7" # required
    service.beta.kubernetes.io/scp-load-balancer-client-cert-id: "24da35de187b450eb0cf09fb6fa146de" # required
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - appProtocol: http # required
      protocol: TCP
      port: 80
      targetPort: 9376
    - appProtocol: https # required
      protocol: TCP
      port: 443
      targetPort: 9898
  type: LoadBalancer
  

Annotation Detailed Settings

You can add annotations to the service manifest to configure detailed functions.

apiVersion: v1
kind: Service
metatdata:
  name: my-lb-svc
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-public-ip-enabled: "true"
    service.beta.kubernetes.io/scp-load-balancer-health-check-interval: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-timeout: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-count: "3"
    service.beta.kubernetes.io/scp-load-balancer-session-duration-time: "300"
  spec:
  type: LoadBalancer
  ...
  

apiVersion: v1
kind: Service
metatdata:
  name: my-lb-svc
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-public-ip-enabled: "true"
    service.beta.kubernetes.io/scp-load-balancer-health-check-interval: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-timeout: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-count: "3"
    service.beta.kubernetes.io/scp-load-balancer-session-duration-time: "300"
  spec:
  type: LoadBalancer
  ...
  

If no separate annotation is added to the service, the default and allowed values of the applied annotation are as follows. Also, check the precautions for each annotation.

Constraints

The constraints to consider when using Kubernetes annotations are as follows.

4 - Considerations for Use

Managed Port Constraints

The following ports are used for SKE management and cannot be used for service use. In addition, if blocked by OS firewall, etc., node functions or some functions may not work normally.

kube-reserved resource constraints

kube-reserved is a feature that reserves resources for system daemons that do not run as pods on the node.

• There are system daemons that do not run as pods, such as kubelet, container runtime, etc.

Kubernetes Engine reserves CPU and memory based on the following criteria.

• Example: For a Virtual Server with 16-core vCPU and 32G Memory, kube-reserved is calculated as follows.

  • CPU: (1 core × 0.06) + (1 core × 0.01) + (2 cores × 0.005) + (12 cores × 0.0025) = 0.11 core
  • Memory: (4 GB × 0.25) + (4 GB × 0.2) + (8 GB × 0.1) + (16 GB × 0.06) = 3.56 GB

• Example: The resources reserved according to CPU size are as follows.

• Example: The resources reserved according to the memory size are as follows.

5 -