30 Aralık 2022 Cuma

Kubernetes kind: NetworkPolicy - Karışık Durumlar

Örnek - namespaceSelector ve podSelector AND ve OR farkı
Açıklaması şöyle
For example, the following NetworkPolicy allows traffic from all Pods in the my-ns namespace that have a role: app label OR from all Pods in any namespaces that have a somelabel: myvalue label:
Şöyle yaparızBurada 2 tane kural "-" ile veriliyor
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-networkpolicy1
  namespace: my-ns
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          somelabel: myvalue
    - podSelector:
        matchLabels:
          role: app
    ports:
    - protocol: TCP
      port: 80
Açıklaması şöyle.
However, a slightly different NetworkPolicy would allow traffic only from Pods that themselves have a label role: app AND that are in namespaces that have a somelabel: myvalue label:
Şöyle yaparızBurada 1 tane kural "-" ile veriliyor. 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-networkpolicy2
  namespace: my-ns
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          somelabel: myvalue
      podSelector:
        matchLabels:
          role: app
    ports:
    - protocol: TCP
      port: 80
Kubernetes v1.21'den sonra otomatik olarak kubernetes.io/metadata.name diye bir label yaratılıyor. Label'ın varsayılan değeri namespace ismi. Şöyle yaparız. Yani fazladan label vermeye gerek yok.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-app-ns
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock: 
      cidr: 172.17.0.0/16
      except:
      - 172.17.1.0/24 
    - namespaceSelector: 
        matchLabels:   
          kubernetes.io/metadata.name: my-client-ns
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978
Örnek - Don’t combine disparate NetworkPolicies
Elimizde şöyle bir policy olsun
# This is bad because it grants access to more than it should
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-network-policy
  namespace: my-ns
spec:
  policyTypes:
  - Egress
  podSelector: {} 
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    - ipBlock:         
        cidr: 93.184.216.34/32
    ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
    - port: 80
      protocol: TCP
Burada hem DNS pod'un 53 ve 80 hem de 93.184.216.34/32 adresinin 53 ve 80 portlarına izin veriliyor. Ancak istenen aslında DNS pod'un 53 portuna, 93.184.216.34/32 adresinin de 80 portuna izin vermek. Doğrusu şöyle
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-allpods-to-dns
  namespace: my-ns
spec:
  policyTypes:
  - Egress
  podSelector: {} 
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
apiVersion: networking.k8s.io/v1 
kind: NetworkPolicy 
metadata:   
  name: allow-cronjob-to-examplecom
  namespace: my-ns
spec: 
  podSelector:     
    matchLabels:       
      app.kubernetes.io/component: cronjob
  policyTypes:   
  - Egress   
  egress:   
  - to:     
    - ipBlock:         
        cidr: 93.184.216.34/32
    ports:     
    - protocol: TCP       
      port: 80



27 Aralık 2022 Salı

kubectl create sa seçeneği

Örnek
Şöyle yaparız
#Create a service account
> kubectl create sa pod-access -n dev
Bu service account'u pod içinde kullanmak için şöyle yaparız
apiVersion: v1
kind: Pod
metadata:
  name: kubectl-pod
spec:
  containers:
  - image: shamimice03/kubectl-image    
    name: kubectl-pod
    command:
    - sleep
    - "10000"
  serviceAccountName: pod-access
Service Account'u incelemek için şöyle yaparız
# Inspect the pod
> kubectl describe pod kubectl-pod | grep -i "service account"
> kubectl describe pod kubectl-pod | grep -A1 Mounts

# View the permission list of a service account
> kubectl auth can-i --list --as=system:serviceaccount:pod-access -n dev

Kubernetes kind: ServiceAccount

Örnek
Elimizde şöyle bir ServiceAccount olsun. ServiceAccount Pod içinde çalışmakta olan process'in kimliğidir
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa
  namespace: default
Artık bu service account'u kullanan 
1. RoleBinding tanımlanabilir
2. Pod tanımlanabilir

Pod için pod tanımda serviceAccountName alanında belirtilir. Şöyle yaparız
apiVersion: v1
kind: Pod
metadata:
  name: kubectl-pod
spec:
  containers:
  - image: shamimice03/kubectl-image    
    name: kubectl-pod
    command:
    - sleep
    - "10000"
  serviceAccountName: pod-access
automountServiceAccountToken Alanı
Açıklaması şöyle
To make sure that the default service account does not get attached to the pods automatically while the service account is not defined, make sure that
automountServiceAccountToken: false parameter is in place for each default service account.
Örnek
Şöyle yaparız
# add "automountServiceAccountToken: false" to the "default" namespace
> kubectl edit sa default -n dev

---
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2022-09-05T07:40:43Z"
  name: default
  namespace: dev
  ....
automountServiceAccountToken: false       #disable automount
---



Service Account in Kubernetes - Kubernetes Authentication (Doğrulama) İçin Gerekir

Giriş
Service account bir token sağlar. Bu token Kubernetes tarafından doğrulama için kullanılır. Şeklen şöyle


Account Tipleri
Açıklaması şöyle.
What Is Service Account in Kubernetes?
There are two types of account in Kubernetes

1. User Account: It is used to allow us, humans, to access the given Kubernetes cluster. Any user needs to get authenticated by the API server to do so. A user account can be an admin or a developer who is trying to access the cluster level resources.

2. Service Account: It is used to authenticate machine level processes to get access to our Kubernetes cluster. The API server is responsible for such authentication to the processes running in the pod
Açıklaması şöyle
So, a service account is an identity that is attached to the processes running within a pod.
Service Account yaratmak için 
1. kind: ServiceAccount yaml kullanılabilir.
2. kubectl create sa kullanılabilir

Service Account İçinde Permission'lar Vardır
- Bu persmission'lar hangi resource'lara create veya get yapılabileceğini gösterir. - Permission'lar ClusterRole ve Role ile değiştirilebilir.
- Default Service Account içinde az sayıda ve çoğunlukla salt okunur permission'lar vardır.

Örnek - Role Değiştirme
Şöyle yaparız. Böylece Role ile pods kaynağına get, watch, list hakkı verilir. kubectl get pods hata dönmez.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: pod-access
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
Örnek - ClusterRole Değiştirme
Şöyle yaparız. cronjobs kaynaklarıyla ilgili her şeye erişim verir.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: job-master
rules:
- apiGroups:
  - batch
  resources:
  - cronjobs
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
Açıklaması şöyle
We will now create two RoleBinding objects (not ClusterRoleBinding) which will use the ClusterRole job-master from above to allow the ServiceAccount sa to perform various actions (verbs) on cronjobs in two namespaces:
Daha sonra şöyle yaparız. roleRef alanında ClusterRole nesnesine atıfta bulunuluyor. subjects alanında kime erişim verildiği belirtiliyor
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: job-master-1
  namespace: namespace1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: job-master
subjects:
- kind: ServiceAccount
  name: sa
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: job-master-2
  namespace: namespace2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: job-master
subjects:
- kind: ServiceAccount
  name: sa
  namespace: default
Denemek için şöyle yaparız
#yes. namespace1 and cronjobs
kubectl auth can-i get cronjobs -n namespace1 --as system:serviceaccount:default:sa

#yes. namespace1 and cronjobs
kubectl auth can-i delete cronjobs -n namespace2 --as system:serviceaccount:default:sa

#no because of namespace3
kubectl auth can-i get cronjobs -n namespace3 --as system:serviceaccount:default:sa #no

#no because of pod
kubectl auth can-i get pod -n namespace2 --as system:serviceaccount:default:sa 
Örnek - ClusterRole Değiştirme
Şöyle yaparız
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pv-sc-access
rules:
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pv-sc-binding
  namespace: dev
subjects:
- kind: ServiceAccount
  name: pod-access          
  namespace: dev #namespace of the service account
roleRef:
  kind: ClusterRole
  name: pv-sc-access
  apiGroup: rbac.authorization.k8s.io
Örnek - Default Service Account
Elimizde bir default service account kullanan pod olsun. Bu pod'un permission'larını deneyelim. Şöyle yaparız. Burada 10.25.96.3:6443 kubernetes servisinin sağladığı bir endpoint. Şu anda /api kaynağına erişmeye çalışıyoruz.
# Enter into the pod
> kubectl exec -it kubectl-pod bash

# Try to access k8s API without SA token 
> curl -X GET https://10.25.96.3:6443/api --insecure

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",  # Access Unsuccessful, Authentication failed.
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/api\"",
  "reason": "Forbidden",
  "details": {},
  "code": 403
}
Bu sefer Service Account Token'ı kullanarak şöyle yaparız. Sonuç başarılı
# Try to access k8s API using SA token
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
> curl -X GET https://10.25.96.3:6443/api/ --header "Authorization: Bearer $TOKEN" \
  --insecure
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.25.96.3:6443"       # Access Successful
    }
  ]
}
Bu sefer Service Account Token'ı kullanarak şöyle yaparız. Sonuç başarılı
# Try to access k8s API securely using SA token and CA.crt
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CA=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
> curl --cacert $CA -X GET https://10.25.96.3:6443/api/ \
  --header "Authorization: Bearer $TOKEN"
{ "kind": "APIVersions", "versions": [ "v1" ], "serverAddressByClientCIDRs": [ { "clientCIDR": "0.0.0.0/0", "serverAddress": "10.25.96.3:6443" #Access Successful } ] }
Şimdi permission'ları deneyelim şöyle yaparız. Sonuç başarısız
# Try to list the all the pods within dev namespace
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CA=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
> curl --cacert $CA -X GET https://10.25.96.3:6443/api/v1/namespaces/dev/pods/ \
 --header "Authorization: Bearer $TOKEN"
{ "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", # Access Unsuccessful, lack of permissions "message": "pods is forbidden: User \"system:serviceaccount:dev:pod-access\" cannot list resource \"pods\" in API group \"\" in the namespace \"dev\"", "reason": "Forbidden", "details": { "kind": "pods" }, "code": 403 }

Differences between the User Account and Service Account
Açıklaması şöyle
User accounts are intended to be global. Names must be unique across all namespaces of a cluster. Service accounts are namespaced.
1. Default Service Account
Açıklaması şöyle
A default service account is automatically created for each namespace. To authenticate with Kubernetes API from pods, the pods must have access to the service account token. Whenever a pod is created without defining service account, it gets attached to the default service account. (a service account token is mounted into the pod in /var/run/secrets/kubernetes.io/serviceaccount
directory)
Açıklaması şöyle
When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace.
Örnek
Şöyle yaparız. Burada dev isimli namespace içinde default service account'un yaratıldığı görülebilir.
# Create namespace
> kubectl create namespace dev

# Change current context to the new context(namespace)
> kubectl config set-context --current --namespace=dev

# View the service accounts of dev namespace
> kubectl get sa
------------------------------------------------------
NAME      SECRETS   AGE
default   0         5m57s
------------------------------------------------------
dev namespace içindeki bir pod'a bakalım. Burada service account'un mount edildiği görülebilir.
# Create a pod
> kubectl run kubectl-pod - image=shamimice03/kubectl-image

# Inspect the pod 
# Check if the service account is mounted or not
> kubectl describe pod kubectl-pod | grep -A1 Mounts
--------------------------------------------------------------------
Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vtm4h (ro)
--------------------------------------------------------------------
Service account'un içine bakmak için şöyle yaparız.
# View the permission list of a service account
> kubectl auth can-i \
  --list \
  --as=system:serviceaccount:<service-account-name> \
  -n <namespace>
Şimdi service account'un içine bakalım.
> kubectl auth can-i \
  --list \
  --as=system:serviceaccount:default \
  -n dev

Resources                                       Non-Resource URLs   Resource Names   Verbs
selfsubjectaccessreviews.authorization.k8s.io   []                  []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                  []               [create]
                                                [/api/*]            []               [get]
                                                [/api]              []               [get]
                                                [/apis/*]           []               [get]
                                                [/apis]             []               [get]
                                                [/healthz]          []               [get]
                                                [/healthz]          []               [get]
                                                [/livez]            []               [get]
                                                [/livez]            []               [get]
                                                [/openapi/*]        []               [get]
                                                [/openapi]          []               [get]
                                                [/readyz]           []               [get]
                                                [/readyz]           []               [get]
                                                [/version/]         []               [get]
                                                [/version/]         []               [get]
                                                [/version]          []               [get]
                                                [/version]          []               [get]


23 Aralık 2022 Cuma

Probe Çeşitleri - Startup Probe

Giriş
Açıklaması şöyle
The startup probe ensures the pod is initiated and created successfully. 
Açıklaması şöyle. Yani Startup aşamasını geçtikten sonra artık Liveness devreye giriyor
If Startup probe succeeds, it is replaced by the Liveness probe which will then be executed normally as configured. If the Startup probe fails, the pod is restarted and the cycle repeated.
SpringBoot İçin Not
Açıklaması şöyle. Actuator tarafından sağlanan liveness zaten Kubernetes Liveness Probe için kullanılacağı için bence /actuator/health/readiness adresini kullanmak daha iyi. Eğer custom bir şey yazılacaksa HealthIndicator kullanılabilir.
Spring Boot does not expose a separate endpoint for the startup probe. You could use the liveness probe, readiness probe, or a custom-developed health indicator for this use case. The reason to have a different probe in Kubernetes is to enable a long timeout for the initial startup of the application, which might take some time. After the first successful startup probe call, the liveness probe takes over, reducing timeout values to detect a failure and restart the application quickly.
Örnek
Şöyle yaparız
startupProbe:
  httpGet:
    path: /probes/liveness
    initialDelaySeconds: 5
    periodSeconds: 5
    timeoutSeconds: 3
    failureThreshold: 18
livenessProbe:
  httpGet:
    path: /probes/liveness
    periodSeconds: 5
    timeoutSeconds: 3
    failureThreshold: 3
Açıklaması şöyle
This configuration sets a Startup probe to be started 5 seconds after the container creation (initialDelaySeconds), and executed every 5 seconds (periodSeconds) with a tolerance to fail 18 times (failureThreshold). So only after the 18th failure, this probe will cause the container to be restarted.

On the other hand (and here is the trick) as we’re using the default success threshold, as soon as it succeeds this probe is deactivated and the Liveness probe starts to be executed, but the later with a more realistic failure threshold of only 3 times.

So packing everything up, now this container have up to 90 seconds to be available at startup but as soon as it becomes available, any problem can be detected in no more than 15 seconds.
Örnek
Şöyle yaparız
startupProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  periodSeconds: 5
  failureThreshold: 30
  initialDelaySeconds: 10
  timeoutSeconds: 1


22 Aralık 2022 Perşembe

helm upgrade seçeneği

Giriş
Açıklaması şöyle
Helm install creates a special type of Kubernetes secret that holds release information and deploys the chart if not present. If Chart is present on the cluster then it will fail. To upgrade any deployed chart release, you need to use an upgrade command. Helm provides another option for chart deployment which verifies the Chart is present or not, in case of yes then it will upgrade the chart or it will install the chart.
Açıklaması şöyle
helm upgradee <release-name> <path-to-chart> — upgrade earlier release with updated chart
helm upgrade <release-name> <path-to-chart> –f <path-to-yaml-file> — upgrade earlier release with updated chart and configuration provide in yaml file
helm upgrade <release-name> helm-chart-demo –set <key-name> = <value>- upgrade earlier release with updated chart and updated value with –set flag
Örnek
Şöyle yaparız
helm upgrade helm-char-demo-r-1 helm-chart-demo –set replicaCount= 2
--install seçeneği
Örnek
Şöyle yaparız
helm upgrade --install elastic-operator elastic/eck-operator
Çıktı olarak şunu alırız. Burada REVISION ile 3. sürüme geçildiği görülebilir
Release "elastic-operator" has been upgraded. Happy Helming!
NAME: elastic-operator LAST DEPLOYED: Wed May 25 09:44:06 2022 NAMESPACE: default STATUS: deployed REVISION: 3 TEST SUITE: None
Aynı bilgiyi "helm status elastic-operator" ile de görebiliriz

helm show seçeneği

Giriş
Bu komutun Helm2'deki karşılığı "helm inspect" Açıklaması şöyle
helm show values <path-to-chart>- show the values from values.yaml file of chart
helm show all <path-to-chart> — show values as well chart details

show values seçeneği
Örnek
Şöyle yaparız
helm repo add jenkinsci https://charts.jenkins.io
helm repo update
helm show values jenkinsci/jenkins > jenkins.yaml

helm rollback seçeneği

Giriş
Söz dizimi şöyle
helm rollback [flags] <chart-release-name> <version>
Açıklaması şöyle
The first argument of the rollback command is the name of a release, and the second is a revision (version) number. If you would like to roll back to the previous release, these arguments can be ignored. The following Helm command can be used to display the revision numbers.
helm history RELEASE
Örnek
Şöyle yaparız
$ helm rollback elastic-operator 2
    

helm uninstall seçeneği

Giriş
Bu komutun Helm2'deki karşılığı "helm delete". Söz dizimi şöyle
helm uninstall <chart-install-name>
--keep-history seçeneği
Örnek
Açıklaması şöyle
Helm uninstall will delete the chart deployed and the history attached to it. But if you want to keep the release information
Şöyle yaparız
helm uninstall --keep-history <chart-install-name>

Kubernetes kind: ResourceQuota - Namespace için ResourceQuota Tanımlar

Örnek
Açıklaması şöyle
Below is an example Kubernetes Manifest that you can use to create a ResourceQuota in a Namespace. The Namespace in this example is called golangapp.

When setting up Resource Quotas in a Namespace, remember that there should be a fair amount of architecture design and decision-making around the process because Pods won’t deploy if the Quota has been met. For example, if you limit the memory to 512Mi, but you try to give a Pod 2GB of memory, there will be an error that looks similar to the below.

Error from server (Forbidden):
  error when creating "name_of_manifest.yaml": pods
"app name" is forbidden:
  exceeded quota: memorylimit
Şöyle yaparız
apiVersion: v1
kind: ResourceQuota
metadata:
  name: memorylimit
  namespace: golangapp
spec:
  hard:
    requests.memory: 512Mi
    limits.memory: 512Mi


21 Aralık 2022 Çarşamba

runc - Low-Level Container Runtime

Şeklen şöyle

Örnek
Şöyle yaparız
# to create a container with runc
$ runc run runc-container
/# echo "Hello from in a container"
Hello from in a container
Runscape
Açıklaması şöyle
If you remember back in 2019, a vulnerability was discovered in runC called Runscape.

This bug (CVE-2019-5736) had the potential to enable hackers to break away from the sandbox environment and gave root access to the host servers. This led to compromising an entire infrastructure. At first, they assumed that it could be a malicious Docker image as there has to be a malicious process inside. After all tests, they realized it was a bug in runC.


19 Aralık 2022 Pazartesi

Kubesec - Static Analysis

scan seçeneği
Şöyle yaparız
>> kubesec scan pod.yaml
critical ve advise başlıkları düzeltilmesi gereken maddeleri listeler. critical olanlar düzeltilmelidir. Ayrıca score başlığı altında toplam puanımız vardır. Bunu da artırmaya çalışmak gerekir

Kubernetes kind: PodSecurityPolicy - Namespace Level

Giriş
Açıklaması şöyle
Previously, there was PodSecurityPolicy (PSP) but from Kubernetes v1.21, PodSecurityPolicy was deprecated and removed from Kubernetes in v1.25.
Yeni Yöntem
Söz dizimi şöyle
# Mandatory
pod-security.kubernetes.io/<MODE>: <LEVEL> 

# Optional        
pod-security.kubernetes.io/<MODE>-version: <VERSION>
Level Ne Demek
Açıklaması şöyle. Kısıtlamalar azdan çoğa doğru sıralı
we have to define one of the pod security standards. Currently, there are three pod security standards available.

Privileged—Unrestricted policy, providing the widest possible level of permissions.

Baseline — Minimally restrictive policy which prevents known privilege escalations. There is a comprehensive list of controls that should be enforced or disallowed. For instance, Privileged Pods must be disallowed if we want to create a pod in the Baseline labeled namespace.

Restricted — Heavily restricted policy, the main purpose of this policy is to follow current pod hardening best practices. Similar to Baseline standards there is a list of controls that should be enforced or disallowed. For instance, no container can have root user permissions. Containers must be run as non-root users.
Mode Ne Demek?
Açıklaması şöyle. Enforce ise eğer bir Level ihlal edilirse Pod reddedilir. Audit veya Warn ise Pod reddedilmez ve çalışır ama uyarı verilir
● enforce — Policy violations will cause the pod to be rejected.

● audit — Policy violations will trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.

● warn — Policy violations will trigger a user-facing warning but are otherwise allowed.
Baseline Level
Pod şunu yaparsa Baseline kabul edilir
    securityContext:
       privileged: true
Restricted Level
Pod şunu yaparsa Restricted kabul edilir
    securityContext:
      runAsUser: 0

Örnek - Baseline + enforce -  Yani Privileged Pod Reject
Elimizde şöyle bir namespace ayarı olsun
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2022-11-08T09:26:17Z"
  labels:
    kubernetes.io/metadata.name: baseline-ns-1
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.25
  name: baseline-ns-1
  resourceVersion: "4779"
  uid: 2a8708f3-6f25-4cfb-84c1-ef6c825e23c5
spec:
  finalizers:
  - kubernetes
status:
  phase: Active
Açıklaması şöyle
Since we applied labels with “enforce” mode and “baseline” pod security standards, if a pod does not respect the “baseline” standard it will be rejected. 
Şu pod başarısız olur
# pod-1.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: pod-1
  name: pod-1
  namespace: baseline-ns-1
spec:
  containers:
  - image: nginx
    name: pod-1
    securityContext:
       privileged: true
Hata şöyle
Error from server (Forbidden): error when creating "pod-1.yaml": pods "pod-1" is forbidden: violates PodSecurity "baseline:v1.25": privileged (container "pod-1" must not set securityContext.privileged=true)
Örnek - Baseline + Warn - Yani Sadece Log
Elimizde şöyle bir namespace ayarı olsun
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2022-11-08T09:26:17Z"
  labels:
    kubernetes.io/metadata.name: baseline-ns-1
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: v1.25
  name: baseline-ns-1
  resourceVersion: "4779"
  uid: 2a8708f3-6f25-4cfb-84c1-ef6c825e23c5
spec:
  finalizers:
  - kubernetes
status:
  phase: Active
Bu sefer çalışır. Çıktı şöyle
Warning: would violate PodSecurity "baseline:v1.25": privileged (container "pod-1" must not set securityContext.privileged=true) pod/pod-1 created
Örnek
Elimizde şöyle bir namespace ayarı olsun
apiVersion: v1
kind: Namespace
metadata:
  name: baseline-ns-2
  labels:
    # baseline Standard with enforce Mode 
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.25
    # restricted Standard with warn Mode
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.25
Şöyle yaparız
# pod-2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  namespace: baseline-ns-2
spec:
  containers:
  - name: pod-2
    image: nginx
    securityContext:
      runAsUser: 0
Pod çalışır. Çünkü root user kullansa bile restricted yani en sıkı kurallar sadece warn. Baseline root user'a izin verdiği için sıkıntı yok.

Eski Yöntem
Örnek
Şöyle yaparız. Böylece işletim sisteminin her türlü yeteneğine erişebilen privileged pod'lar yasaklanır
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # Don't allow privileged pods!

13 Aralık 2022 Salı

kind komutu - minikube Alternatifi

Giriş
Açıklaması şöyle
kind is a tool for running local Kubernetes clusters using Docker container “nodes”. kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
Kurulum
Şöyle yaparız
brew install kind
Eğer podman ile kullanmak istiyorsak şöyle yaparız
export KIND_EXPERIMENTAL_PROVIDER=podman
create cluster
Örnek
Şöyle yaparız
kind create cluster
Örnek
Elimizde şöyle bir YAML olsun. 3 tane düğümlü bir cluster yaratır
# kind.config.yaml

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: api-server-discovery

nodes:
- role: control-plane
- role: worker
- role: worker
Şöyle yaparız
kind create cluster --config=kind.config.yaml
Silmek için şöyle yaparız
kind delete cluster --name api-server-discovery







8 Aralık 2022 Perşembe

bash auto-completion on Linux

Giriş
Tüm açıklamalar burada

1. bash autocompletion kurulur. Şöyle yaparız
apt-get install bash-completion
# veya
yum install bash-completion
Eğer kurmadan önce zaten kurulumu diye kontrol etmek istersek şöyle yaparız. Burada type komutu ile bir bash fonksiyonu aranıyor. Bulunursa bir çıktı verecektir.
type _init_completion

2. kubectl autocompletion etkinleştirilir
Şöyle yaparız
# User
echo 'source <(kubectl completion bash)' >>~/.bashrc

# veya System
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
Daha sonra bir alias tanımlarız ve alias için auto-completion etkinleştirilir. Şöyle yaparız
# If you have an alias for kubectl, you can extend shell completion to work with that alias:
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc
Daha sonra "k -" yazıp tab tuşuna iki kere basınca kullanılabilecek seçenekler gösterilir.

Cluster Propotional Autoscaler - ReplicaSet Ekler/Siler

Giriş Açıklaması şöyle CPA aims to horizontally scale the number of Pod replicas based on the cluster’s scale. A common example is DNS ser...