In IBM Cloud Private EE, I need to go to the Web UI User > Configure client, copy the kubectl config commands and then run these 5 commands on my client machine.
I deployed the IBM Cloud private EE on 5 VMs and have access to the master node. I am wondering if there is a way to capture these kubectl config commands directly from the docker containers without having a need to go to the Web UI.
For example: I did not want to download the kubectl client from google (as I just want to use same kubectl version which is in the ICP containers) and I used the following command to get it from the container itself.
docker run --rm -v $(pwd):/data -e LICENSE=accept \
ibmcom/icp-inception:2.1.0.1-ee \
cp -r /usr/local/bin/kubectl /data
Then, I copied this to all VM guests so that I could access kubectl from any guest.
chmod +x kubectl
for host in $(awk '/192.168.142/ {print $3}' /etc/hosts)
do
scp kubectl $host:/bin
done
Where - 192.168.142 is the subnet of my VM guests.
But, I could not figure out how to get Configure Client commands without having to go to the Web UI. I need this to automate client kubectl command so that my environment is ready for kubectl commands through simple scripts.
You should use Vagrant to automate those steps.
For instance, IBM/deploy-ibm-cloud-private/Vagrantfile has this section:
install_kubectl = <<SCRIPT
echo "Pulling #{image_repo}/kubernetes:v#{k8s_version}..."
sudo docker run -e LICENSE=#{license} --net=host -v /usr/local/bin:/data #{image_repo}/kubernetes:v#{k8s_version} cp /kubectl /data &> /dev/null
kubectl config set-credentials icpadmin --username=admin --password=admin &> /dev/null
kubectl config set-cluster icp --server=http://127.0.0.1:8888 --insecure-skip-tls-verify=true &> /dev/null
kubectl config set-context icp --cluster=icp --user=admin --namespace=default &> /dev/null
kubectl config use-context icp &> /dev/null
SCRIPT
See more at "Kubernetes, IBM Cloud Private, and Vagrant, oh my!", from Tim Pouyer.
#VonC provided useful tips. This is how the service account token can be obtained.
Get the token from a running container - Tip from this link.
RUNNIGCONTAINER=$(docker ps | grep k8s_cloudiam-apikeys_auth | awk '{print $1}')
TOKEN=$(docker exec -t $RUNNIGCONTAINER cat /var/run/secrets/kubernetes.io/serviceaccount/token)
I already know the name of the IBM Cloud Private cluster name, master node and the default user name. The only missing link was the token. Please note that the script used by Tim is using password and the only difference was - I wanted to use token instead of the password.
So use the scripts.
kubectl config set-cluster ${CLUSTERNAME}.icp --server=https://$MASTERNODE:8001 --insecure-skip-tls-verify=true
kubectl config set-context ${CLUSTERNAME}.icp-context --cluster=${CLUSTERNAME}.icp
kubectl config set-credentials admin --token=$TOKEN
kubectl config set-context ${CLUSTERNAME}.icp-context --user=$DEFAULTUSERNAME --namespace=default
kubectl config use-context ${CLUSTERNAME}.icp-context
# get token
icp_auth_token=`curl -s -k -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" \
-d "grant_type=password&username=${myuser}&password=${mypass}&scope=openid" \
https://${icp_server}:8443/idprovider/v1/auth/identitytoken --insecure | \
sed 's/{//g;s/}//g;s/\"//g' | \
awk -F ':' '{print $7}'`
# setup context
kubectl config set-cluster ${icp_server} --server=https://${icp_server}:8001 --insecure-skip-tls-verify=true
kubectl config set-credentials ${icp_server}-user --token=${icp_auth_token}
kubectl config set-context ${icp_server}-context --cluster=${icp_server} --user=${icp_server}-user
kubectl config use-context ${icp_server}-context
Related
Using Helm 3 installed OpenLDAP:
helm install openldap stable/openldap
Got this message:
NAME: openldap
LAST DEPLOYED: Sun Apr 12 13:54:45 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
OpenLDAP has been installed. You can access the server from within the k8s cluster using:
openldap.default.svc.cluster.local:389
You can access the LDAP adminPassword and configPassword using:
kubectl get secret --namespace default openldap -o jsonpath="{.data.LDAP_ADMIN_PASSWORD}" | base64 --decode; echo
kubectl get secret --namespace default openldap -o jsonpath="{.data.LDAP_CONFIG_PASSWORD}" | base64 --decode; echo
You can access the LDAP service, from within the cluster (or with kubectl port-forward) with a command like (replace password and domain):
ldapsearch -x -H ldap://openldap.default.svc.cluster.local:389 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w $LDAP_ADMIN_PASSWORD
Test server health using Helm test:
helm test openldap
You can also consider installing the helm chart for phpldapadmin to manage this instance of OpenLDAP, or install Apache Directory Studio, and connect using kubectl port-forward.
However I can't use this command to search content on ldap server in the k8s cluster:
export LDAP_ADMIN_PASSWORD=[REAL_PASSWORD_GET_ABOVE]
ldapsearch -x -H ldap://openldap.default.svc.cluster.local:389 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w $LDAP_ADMIN_PASSWORD
Got error
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
I also login to the pod to run
kubectl exec -it openldap -- /bin/bash
# export LDAP_ADMIN_PASSWORD=[REAL_PASSWORD_GET_ABOVE]
# ldapsearch -x -H ldap://openldap.default.svc.cluster.local:389 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w $LDAP_ADMIN_PASSWORD
The same.
As it's stated in the notes:
NOTES:
OpenLDAP has been installed. You can access the server from within the k8s cluster using:
openldap.default.svc.cluster.local:389
You can access the LDAP adminPassword and configPassword using:
kubectl get secret --namespace default openldap -o jsonpath="{.data.LDAP_ADMIN_PASSWORD}" | base64 --decode; echo
kubectl get secret --namespace default openldap -o jsonpath="{.data.LDAP_CONFIG_PASSWORD}" | base64 --decode; echo
You can access the LDAP service, from within the cluster (or with kubectl port-forward) with a command like (replace password and domain):
ldapsearch -x -H ldap://openldap.default.svc.cluster.local:389 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w $LDAP_ADMIN_PASSWORD
Test server health using Helm test:
helm test openldap
You can also consider installing the helm chart for phpldapadmin to manage this instance of OpenLDAP, or install Apache Directory Studio, and connect using kubectl port-forward.
You can do:
$ kubectl port-forward services/openldap 3389:389
Forwarding from 127.0.0.1:3389 -> 389
Forwarding from [::1]:3389 -> 389
Handling connection for 3389
From another shell, outside the Kubernetes cluster:
$ kubectl get secret --namespace default openldap -o jsonpath="{.data.LDAP_ADMIN_PASSWORD}" | base64 --decode; echo
l3dkQByvzKKboCWQRyyQl96ulnGLScIx
$ ldapsearch -x -H ldap://localhost:3389 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w l3dkQByvzKKboCWQRyyQl96ulnGLScIx
Also it was already mentioned in a comment by #Totem
My password once worked, but I don't remember if I changed it or not.
However, I can't reset it.
I tried with no success:
kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo
> DpveUuOyxNrandompasswordYuB5Fs2cEKKOmG <-- does not work (anymore?)
PS: I did not set any admin email for web-based reset
Ok found.
Best way is to run grafana-cli inside grafana's pod.
kubectl exec --namespace default -it $(kubectl get pods --namespace default -l "app=grafana,release=grafana" -o jsonpath="{.items[0].metadata.name}") grafana-cli admin reset-admin-password yourNewPasswordHere
INFO[01-21|10:24:17] Connecting to DB logger=sqlstore dbtype=sqlite3
INFO[01-21|10:24:17] Starting DB migration logger=migrator
Admin password changed successfully ✔
Okay, try this.
kubectl get pod -n monitoring
kubectl exec -it grafana-00000000aa-lpwkk -n monitoring -- sh
grafana-cli admin reset-admin-password NEWPASSWORD
If you installed it via kube-prometheus-stack helm chart then the admin password is stored in a secret named kube-prometheus-stack-grafana. You need to set it there are restart the Grafana pod.
Alternatively, you can just decode the password and use:
kubectl get secrets/kube-prometheus-stack-grafana -o json | jq '.data | map_values(#base64d)'
I am trying to perform a simple operation of logging into my cluster to update image of a deployment. I am stuck at the first step. I get an error that connection to localhost:8080 is refused. Please help.
$ chmod u+x kubectl && mv kubectl /bin/kubectl
$ $KUBE_CERT > ca.crt
$ kubectl config set-cluster cfc --server=$KUBE_URL --certificate-authority=ca.crt
Cluster "cfc" set.
$ kubectl config set-context cfc --cluster=cfc
Context "cfc" created.
$ kubectl config set-credentials gitlab-admin --token=$KUBE_TOKEN
User "gitlab-admin" set.
$ kubectl config set-context cfc --user=gitlab-admin
Context "cfc" modified.
$ kubectl config use-context cfc
Switched to context "cfc".
$ echo "Deploying dashboard with version extracted from tag ${CI_COMMIT_TAG}"
Deploying dashboard with version extracted from tag dev-1.0.4-22
$ kubectl get pods
The connection to the server localhost:8080 was refused - did you specify the right host or port?
The reason why you have you connection refused is because your proxy is not started. Try executing code below so kubectl can access the cluster via proxy (localhost:8080).
kubectl proxy --address 0.0.0.0 --accept-hosts '.*' &
Another approach is to use curl and operate with your cluster just like in the following example:
curl --cacert /path/to/cert -H "Bearer {your token}" "${KUBE_URL}/api"
Upon creating a service account, it seems to be getting access to all resources by default (as if it gets a copy of all my permissions). This is on GKE.
Are Service Accounts supposed to have default access to resources (upon SA creation), or am I missing something?
As per bitnami guide, service account by default will not have access to any resource until it is assigned Roles/ClusterRoles via respective bindings.
This is a simple bash script I'm running to depict the issue I'm seeing.
original_context=ehealth-dev
kubectl create sa eugene-test --context $original_context
sa_secret=$(kubectl get sa eugene-test --context $original_context -o json | jq -r .secrets[].name)
kubectl get secret --context $original_context $sa_secret -o json | jq -r '.data["ca.crt"]' | base64 -D > /tmp/my_ca.crt
user_token=$(kubectl get secret --context $original_context $sa_secret -o json | jq -r '.data["token"]' | base64 -D)
original_cluster_name=my_long_cluster_name
endpoint=`kubectl config view -o jsonpath="{.clusters[?(#.name == \"$original_cluster_name\")].cluster.server}"`
kubectl config set-credentials my_user --token=$user_token
kubectl config set-cluster my_cluster \
--embed-certs=true \
--server=$endpoint \
--certificate-authority=/tmp/my_ca.crt
kubectl config set-context my_context \
--cluster=my_cluster \
--user=my_user \
--namespace=default
kubectl config use-context my_context
kubectl get pods -n my_namespace # ------ it works! :-(
kubectl delete sa eugene-test --context $original_context
kubectl config delete-cluster my_cluster
Early versions of GKE enabled static authorization that gave all service accounts full API permissions. That is no longer the default as of 1.8.
Versions prior to 1.8 can disable this permissive permission with the --no-enable-legacy-authorization flag to gcloud
I'm trying to start a dashboard inside play-with-kubernetes
Commands I'm running:
start admin node
kubeadm init --apiserver-advertise-address $(hostname -i)
start network
kubectl apply -n kube-system -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
allow master to hold nodes(?)
kubectl taint nodes --all node-role.kubernetes.io/master-
Wait until dns is up
kubectl get pods --all-namespaces
join node (copy from admin startup, not from here)
kubeadm join --token 43d52c.d72308004d523ac4 10.0.21.3:6443
download and run dashboard
curl -L -s https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml | sed 's/targetPort: 8443/targetPort: 8443\n type: NodePort/' | \
kubectl apply -f -
Unfortunatelly dashboard is not available.
What should I do to correctly deploy it inside play-with-kubernetes?
You need heapster for dashboard to work. So execute these as well:
kubectl apply -f https://github.com/kubernetes/heapster/raw/master/deploy/kube-config/rbac/heapster-rbac.yaml
kubectl apply -f https://github.com/kubernetes/heapster/raw/master/deploy/kube-config/influxdb/heapster.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/influxdb.yaml
Also, unless you want to fiddle with authentication you need to grant dashboard admin privileges with something like this:
kubectl create clusterrolebinding insecure-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard
Eventually a port link will appear (30xxx) but you will need to change the url scheme to https from http - and convince your browser that you don't care about the insecure certificate.
You should have a working dashboard now. Piece of cake ;)