среда, 5 июня 2019 г.

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.

понедельник, 29 апреля 2019 г.

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).
 

пятница, 19 апреля 2019 г.

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
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.
SEMMNS = SEMMNU = (SEMMNI * SEMMSL)

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

пятница, 8 февраля 2019 г.

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