Sync

.gitignore

@@ -0,0 +1 @@
+.obsidian/

vlads-notes/0001-working-with-kube-config.md

@@ -0,0 +1,51 @@
+---
+title: Working with K8s config
+tags:
+  - learning-notes
+  - k8s
+draft: true
+date: 2025-11-15
+---
+### Intro
+
+In Kubernetes, users and other applications interact with clusters via the API provided by the **kube-apiserver** component. During the bootstrap process, a config file is generated for the user which stores the connectivity details and credentials needed to interact with the cluster via its API.
+In order to use the **kubectl** utility to interact with the cluster, the users must make this generated config file available in "~/.kube/config" so that the binary can authenticate to the cluster.
+
+By default, the config file generated during the cluster bootstrapping contains credentials for accessing the cluster with full admin privileges. Good practice dictates that this level of access should not be granted to users that do not explicitly require it, hence giving this file to everybody who needs access to the cluster is a bad idea!
+
+It is therefor important to understand the structure of this file and how to create versions of it for other users with the right level of access.
+
+Let's look at how to set up new users with their own TLS credentials and the appropriate levels of access
+
+References:
+- https://kubernetes-tutorial.schoolofdevops.com/configuring_authentication_and_authorization/#exercise
+- https://kubernetes.io/docs/reference/access-authn-authz/rbac/
+
+### Prerequisites
+
+You will need access to a K8s cluster and a Linux host with the **kubectl** client available and configured with full admin cluster access (using the default cluster config generated during bootstrapping). 
+
+### Setting up a new user for the cluster
+
+Each user needs their own TLS certificate and key with which to authenticate to the cluster API. You can use **openssl** to create them:
+
+```
+cd ~/.kube
+mkdir users
+cd users
+
+# User 1 will be a cluster admin
+openssl genrsa -out user1.key 2048
+openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=admins/O=learning.lab"
+
+# User 2 will only have access to one namespace
+openssl genrsa -out user2.key 2048
+openssl req -new -key user2.key -out user2.csr -subj "/CN=user2/O=namespace/O=learning.lab"
+```
+
+Copy the cluster's TLS client CA certificate and key from the master node to the local directory. For vanilla K8s they can be found in "/etc/kubernetes/pki"; for K3s they are in "/var/lib/rancher/k3s/server/tls",
+
+```
+cd /var/lib/rancher/k3s/server/tls
+cp client-ca.crt client-ca.crt ~/.kube/users
+```

vlads-notes/0002-command-reference.md

@@ -0,0 +1,57 @@
+---
+title: Command references
+tags:
+  - learning-notes
+  - linux
+draft: false
+date: 2025-11-15
+---
+## Debian (bash)
+
+### OpenSSL
+
+Inspect SSL certificates:
+
+```
+# Display all info
+openssl x509 -text -in certificate.crt
+
+# Display only subject and validity info 
+openssl x509 -subject -dates -in certificate.crt
+```
+
+Generate SSL key and certificate request:
+
+```
+# Generate a key
+openssl genrsa -out user.key 2048
+
+# Generate a CSR with a minimal config
+openssl req -new -key user.key -out user.csr -subj "/CN=user/O=admins/O=learning.lab"
+
+# Generate a CSR with config from a file
+openssl req -new -key user.key -out user.csr -config ssl_conf.conf
+```
+
+### VIM
+
+Search and replace:
+```
+# All instance in current line
+:s/original/replaced/g
+
+# All instances in all lines
+:%s/original/replaced/g
+
+# All instances in all lines, asks for confirmation
+:%s/original/replaced/gc
+```
+
+## K8s utilities
+
+### Kubeseal
+
+Retrieve the public certificate of the controller:
+```
+kubeseal --controler-namespace <NAMESPACE> --controller-name sealed-secrets --fetch-cert >mycert.pem
+```