A Read Only Kubernetes Dashboard

Source

the default configuration for the dashboard does not give it permissions to see anything within the cluster. The dashboard page acknowledges this and suggests simply binding the dashboard service account to cluster-admin…YIKES:

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kube-system

Ugh! Thats not OK. Better would be a read only user…like the ‘view’ ClusterRole:
But there’s a problem - the view ClusterRole doesn’t actually have permissions for the Cluster level objects like Nodes and Persistent Volume Claims. So we’ll have to create a new RBAC config.
First, we’ll create a new dashboard-viewonly ClusterRole:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dashboard-viewonly
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - persistentvolumeclaims
  - pods
  - replicationcontrollers
  - replicationcontrollers/scale
  - serviceaccounts
  - services
  - nodes
  - persistentvolumeclaims
  - persistentvolumes
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - bindings
  - events
  - limitranges
  - namespaces/status
  - pods/log
  - pods/status
  - replicationcontrollers/status
  - resourcequotas
  - resourcequotas/status
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - daemonsets
  - deployments
  - deployments/scale
  - replicasets
  - replicasets/scale
  - statefulsets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - batch
  resources:
  - cronjobs
  - jobs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions
  resources:
  - daemonsets
  - deployments
  - deployments/scale
  - ingresses
  - networkpolicies
  - replicasets
  - replicasets/scale
  - replicationcontrollers/scale
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - networkpolicies
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - storage.k8s.io
  resources:
  - storageclasses
  - volumeattachments
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterrolebindings
  - clusterroles
  - roles
  - rolebindings
  verbs:
  - get
  - list
  - watch

And then bind it to the service account:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubernetes-dashboard 

  namespace: kube-system 

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard
  labels:
    k8s-app: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: dashboard-viewonly
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system

Now we’ve configured a readonly dashboard we can safely share with people that dont even have K8S cluster access (many devs dont - they just push via a CI/CD pipeline). As a side note, this RBAC config does NOT grant access to Secrets, just to be a little safe.

Set AD SPN record for MS SQL service account

 Source

1. Granting read/write servicePrincipalName permissions to the service account using ADSI Edit, as described in https://support.microsoft.com/en-us/kb/811889
2. Removing the SPNs that previously existed on the SQL Server computer account (as opposed to the service account) using
   
   

   setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME

   
   where 1234 was the port number used by the instance (mine was not a default instance).

Linux - Kernel Semaphore parameters

Source

1 - About

On Linux, A semaphore is a System V IPC object that is used to control utilization of a particular process.
Semaphores are a shareable resource that take on a non-negative integer value. They are manipulated by the P (wait) and V (signal) functions, which decrement and increment the semaphore, respectively. When a process needs a resource, a “wait” is issued and the semaphore is decremented. When the semaphore contains a value of zero, the resources are not available and the calling process spins or blocks (as appropriate) until resources are available. When a process releases a resource controlled by a semaphore, it increments the semaphore and the waiting processes are notified.
The Semaphore Kernel parameters

Semaphore	Description	Minimum
SEMMSL	maximum number of semaphores per array	128
SEMMNS	maximum semaphores system-wide
SEMOPM	maximum operations per semop call
SEMMNI	maximum arrays

2 - Articles Related

• Linux - Kernel Parameter Management (sysctl.conf)
• Timesten - Database Installation and configuration on Linux
• Linux - Directory /proc/sys/kernel/
• Linux - System V Shared Memory IPC
• Oracle Database - Installation 11g Release 2 (11.2) on Linux OEL 5 (X86)
• Oracle Database 11gR2 - Installation on Linux OEL 5 Update 5 (x86_64)
• Exalytics - Timesten Configuration
• Linux - IPCS command

Advertising

3 - How to

3.1 - Display them ?

This command displays the value of the semaphore parameters:

# /sbin/sysctl -a | grep sem

3.2 - Calculate them ?

• Calculate the minimum total semaphore requirements using the following formula:

sum (process parameters of all database instances on the system) + system and other application requirements

• Set semmns (total semaphores systemwide) to this total.
• Set semmsl (semaphores per set) to 256.
• Set semmni (total semaphores sets) to semmns / semmsl rounded up to the nearest multiple of 1024.

The following formula can be used as a guide, although in practice, SEMMNS and SEMMNU can be much less than SEMMNI * SEMMSL because not every program in the system needs semaphores.

3.3 - Set them ?

In the file, /etc/sysctl.conf

kernel.sem = 2200 6400 200 25

Where:

kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI

Then reboot or run this command:

# /sbin/sysctl -p

Advertising

4 - Documentation / Reference

• Semaphore (programming)
• Semaphore

Systemd. How to clear journalctl.

Source

1) The self maintenance method is to vacuum the logs by size or time.
Retain only the past two days:

journalctl --vacuum-time=2d

Retain only the past 500 MB:

journalctl --vacuum-size=500M

man journalctl for more information.

 2) You don't typically clear the journal yourself. That is managed by systemd itself and old logs are rotated out as new data comes in. The correct thing to do would be to schedule journald to only keep as much data as you are interested in. The most usual thing to adjust is the total disk space it is allowed to take up. Once it crosses this boundry it will start pitching old entries to stay near this value.

You can set this in /etc/systemd/journald.conf like so:

SystemMaxUse=100M

3) To get rid of everything, you need to rotate the files first so that recent entries are moved to inactive files.

So, the complete answer to remove all entries seems to be
journalctl --rotate journalctl --vacuum-time=1s (Note that you cannot combine this into one journalctl command.)
By the way, some distributions have journald configured so that it writes logs to disk (/var/log/journal) while others keep logs in memory (/run/log/journal). I expect that in some cases it may be necessary to use journalctl --flush first to get everything removed.
If you don't have --rotate in your version, you can use the --since argument to filter entries:
--since "2019-01-30 14:00:00" --since today