Related documents

Body

#[Target Cluster]
## ServiceAccount 생성
export KUBE_SA=jenkins
export KUBE_NS=jenkins-Enterprise Cloud
kubectl create sa -n ${KUBE_NS} ${KUBE_SA}
## SA ClusterRoleBinding 생성
-
## 인증토큰 얻기
kubectl get secret -n ${KUBE_NS} $(kubectl get sa -n ${KUBE_NS} ${KUBE_SA} -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 -d

#[Source Cluster]
kubectl config set-cluster Enterprise Cloud --server=https://127.0.0.1:6443 --insecure-skip-tls-verify
kubectl config set-context jenkins@Enterprise Cloud --user=jenkins --cluster=Enterprise Cloud


sudo vi /etc/kubernetes/admin.conf
>>>
#추가된 클러스터에 항목 추가
## insecure-skip-tls-verify or certificate-authority-data중 택1
insecure-skip-tls-verify: true
certificate-authority-data: ${fromTargetKubeconfig}

## clusters
#proxy-url: https://100.0.0.191:26443 
# 해당 서버 내 apiserver.crt가 허용하는 SAN으로 /etc/hosts에 등록
server: https://127.0.0.1:6443 
server: https://100.0.0.191:26443 

## users
#users에 $TOKEN 추가
- name: jenkins
  user:
    token: {입력}
<<<

kubectl config use-context jenkins@Enterprise Cloud



##정리필요 coredns config
hosts {
           192.168.65.166 lb-apiserver.kubernetes.local
           fallthrough
        }

GPT::Create Resource: SA and Role

Source cluster (where the service account is located):

• Create or use an existing service account:
• Create or use an existing service account on the source cluster you want to grant access to. You can create this in a specific namespace.

1. Define RBAC roles on the source cluster:
   – Create a role, or ClusterRole, on the source cluster that defines the permissions the service account should have. This role allows the service account to access resources on the target cluster.
   – Example YAML for a role granting read access to a pod:

apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: access-target-cluster
     namespace: source-namespace
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list"]

2. Create a RoleBinding for the source service account:
   – Create a RoleBinding that links the role created in step 2 with the service account in step 1.
   – YAML example for RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: access-target-cluster-binding
     namespace: source-namespace
   subjects:
   - kind: ServiceAccount
     name: your-service-account
     namespace: source-namespace
   roleRef:
     kind: Role
     name: access-target-cluster
     apiGroup: rbac.authorization.k8s.io

Target cluster (where access is allowed):

• Create or use an existing namespace:
• Create or use an existing namespace on the target cluster from which the service account on the source cluster will access resources.

1. Define RBAC roles on the target cluster:
   – Create a Role or ClusterRole on the target cluster that defines permissions for the service account on the source cluster to access resources within the target cluster.
   – Example YAML for a role granting read access to pods in the target namespace:

apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: allow-access-from-source
     namespace: target-namespace
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "list"]

2. Create a RoleBinding for the source service account:
   – Create a RoleBinding in the target cluster’s namespace that associates the role created in step 2 with a service account on the source cluster.
   – YAML example for RoleBinding in target cluster:

apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: allow-access-binding
     namespace: target-namespace
   subjects:
   - kind: ServiceAccount
     name: your-service-account
     namespace: source-namespace
   roleRef:
     kind: Role
     name: allow-access-from-source
     apiGroup: rbac.authorization.k8s.io

Connectivity and Access:

Once these configurations are applied, the service account on the source cluster (your-service-account in the source-namespace) will have the permissions defined by the access-target-cluster role to access resources in the namespace of the target cluster. (target namespace). The RoleBinding ‘access-target-cluster-bound’ on the source cluster and the RoleBinding ‘allow-access-bound’ on the target cluster establish the association between service accounts and permissions.

Ensure that the networking between the clusters is properly configured to allow communication, and that the authentication mechanism (such as a kubeconfig file or other authentication method) is set up correctly so that the service account can access both clusters.

GPT::Setting: Kubeconfig

Source cluster (where the service account is located):

• Create or use an existing service account:
• Create or use an existing service account on the source cluster you want to grant access to. You can create this in a specific namespace.

1. Create kubeconfig for the source service account:
   – Create a kubeconfig file for your service account. This kubeconfig is used by the service account to authenticate and access the target cluster.
   – Use the kubectl config command with the -as and -as-group flags to create a kubeconfig that impersonates the service account.

kubectl config set-credentials your-service-account --token=your-service-account-token
   kubectl config set-context target-cluster-context --user=your-service-account --cluster=target-cluster
   kubectl config use-context target-cluster-context

Replace ‘your-service-account’ with the actual name of your service account, ‘your-service-account-token’ with the actual service account token, and ‘target-cluster’ with the name of your target cluster context.

Target cluster (where access is allowed):

1. Create or use an existing namespace:
   – Create or use an existing namespace on the target cluster from which the service account on the source cluster will access resources.
2. Define RBAC roles on the target cluster:
   – Create a Role or ClusterRole on the target cluster that defines permissions for the service account on the source cluster to access resources within the target cluster.
3. Create a RoleBinding for the source service account:
   – Create a RoleBinding in the target cluster’s namespace that associates the role created in step 2 with a service account on the source cluster.

Access from source cluster:

• Copy Kubeconfig:
• Copy the kubeconfig file that you created for the source cluster’s service account to a location that can be accessed by the application or process that will use it.

1. Access resources on the target cluster:
   – Use the copied kubeconfig file to access resources on the target cluster as a service account. For example, you can use the kubectl command with the -kubeconfig flag.

kubectl --kubeconfig=path/to/source-service-account-kubeconfig.yaml get pods -n target-namespace

This configuration allows service accounts on the source cluster to access resources in the target cluster namespace. The service account impersonates itself using the generated kubeconfig, and the RBAC configuration on the target cluster grants the necessary permissions.

Ensure that the kubeconfig file remains secure and that the network configuration between clusters allows communication. We also recommend using advanced tools such as Kubernetes federation or service mesh (such as Istio) for more sophisticated multi-cluster management and communication scenarios.

GPT::Get Secret Token of SA

To obtain an authentication token to register with the kubeconfig file, you typically need to follow these steps:

1. Create a service account: First, you need to create a Kubernetes service account. A service account is the identity that Kubernetes pods and other resources use to authenticate to your cluster.

apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-service-account

Apply the service account configuration using kubectl apply -f service-account.yaml.

2. Binding Role and RoleBinding: Next, you need to grant the required permissions to the service account using Role and RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: my-role
   rules:
   - apiGroups: [""]
     resources: ["pods", "pods/exec"]
     verbs: ["get", "list", "create", "delete"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: my-role-binding
   subjects:
   - kind: ServiceAccount
     name: my-service-account
   roleRef:
     kind: Role
     name: my-role
     apiGroup: rbac.authorization.k8s.io

Apply the role and RoleBinding configuration using kubectl apply -f role-and-role-binding.yaml.

3. Token Retrieval: The token associated with a service account can be found in the service account’s secret. Retrieve the token using:

SECRET_NAME=$(kubectl get sa my-service-account -o jsonpath='{.secrets[0].name}')
   TOKEN=$(kubectl get secret $SECRET_NAME -o jsonpath='{.data.token}' | base64 --decode)
   echo $TOKEN

4. Create or modify kubeconfig: You can now use the retrieved token to create or modify a kubeconfig file. Replace CLUSTER_NAME, SERVER_URL, CONTEXT_NAME with your actual cluster details.

apiVersion: v1
   clusters:
   - name: CLUSTER_NAME
     cluster:
       server: SERVER_URL
       certificate-authority-data: CERTIFICATE_AUTHORITY_DATA
   contexts:
   - name: CONTEXT_NAME
     context:
       cluster: CLUSTER_NAME
       user: my-service-account
   current-context: CONTEXT_NAME
   kind: Config
   preferences: {}
   users:
   - name: my-service-account
     user:
       token: $TOKEN

Replace SERVER_URL with the API server URL of your Kubernetes cluster and CERTIFICATE_AUTHORITY_DATA with your base64 encoded certificate authority data.

5. Set the KUBECONFIG environment variable: Set the KUBECONFIG environment variable to point to the modified kubeconfig file.

export KUBECONFIG=/path/to/modified/kubeconfig.yaml

You can now use the kubectl command with the permissions granted to your service account. These steps assume a simplified scenario. Your actual setup may require additional configuration depending on your environment and use case.