Skip to content

Commit

Permalink
fix: fix chart releaser (#63)
Browse files Browse the repository at this point in the history
reset version to 0.1.0, removing duplicate releases
  • Loading branch information
pns-nirmata authored Apr 24, 2023
1 parent 4107a9f commit 859fca8
Show file tree
Hide file tree
Showing 22 changed files with 897 additions and 0 deletions.
14 changes: 14 additions & 0 deletions charts/best-practices-k8s/Chart.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
apiVersion: v2
name: kubernetes-best-practice-policies
description: Kubernetes Best Practice policy set
type: application
version: 0.1.0
appVersion: 0.1.0
keywords:
- kubernetes
- nirmata
- kyverno
- policy
maintainers:
- name: Nirmata
url: https://nirmata.com/
47 changes: 47 additions & 0 deletions charts/best-practices-k8s/pols/add-networkpolicy-dns.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-networkpolicy-dns
annotations:
policies.kyverno.io/title: Add Network Policy for DNS
policies.kyverno.io/category: Multi-Tenancy, EKS Best Practices
policies.kyverno.io/subject: NetworkPolicy
kyverno.io/kyverno-version: 1.6.2
policies.kyverno.io/minversion: 1.6.0
kyverno.io/kubernetes-version: "1.23"
policies.kyverno.io/description: >-
By default, Kubernetes allows communications across all Pods within a cluster.
The NetworkPolicy resource and a CNI plug-in that supports NetworkPolicy must be used to restrict
communications. A default NetworkPolicy should be configured for each Namespace to
default deny all ingress and egress traffic to the Pods in the Namespace. Application
teams can then configure additional NetworkPolicy resources to allow desired traffic
to application Pods from select sources. This policy will create a new NetworkPolicy resource
named `default-deny` which will deny all traffic anytime a new Namespace is created.
spec:
rules:
- name: add-netpol-dns
match:
any:
- resources:
kinds:
- Namespace
generate:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
name: allow-dns
namespace: "{{request.object.metadata.name}}"
synchronize: false
data:
spec:
podSelector:
matchLabels: {}
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: kube-system
ports:
- protocol: UDP
port: 53
39 changes: 39 additions & 0 deletions charts/best-practices-k8s/pols/add_network_policy.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-networkpolicy
annotations:
policies.kyverno.io/title: Add Network Policy
policies.kyverno.io/category: Multi-Tenancy, EKS Best Practices
policies.kyverno.io/subject: NetworkPolicy
policies.kyverno.io/minversion: 1.6.0
policies.kyverno.io/description: >-
By default, Kubernetes allows communications across all Pods within a cluster.
The NetworkPolicy resource and a CNI plug-in that supports NetworkPolicy must be used to restrict
communications. A default NetworkPolicy should be configured for each Namespace to
default deny all ingress and egress traffic to the Pods in the Namespace. Application
teams can then configure additional NetworkPolicy resources to allow desired traffic
to application Pods from select sources. This policy will create a new NetworkPolicy resource
named `default-deny` which will deny all traffic anytime a new Namespace is created.
spec:
rules:
- name: default-deny
match:
any:
- resources:
kinds:
- Namespace
generate:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
name: default-deny
namespace: "{{request.object.metadata.name}}"
synchronize: true
data:
spec:
# select all pods in the namespace
podSelector: {}
# deny all traffic
policyTypes:
- Ingress
- Egress
58 changes: 58 additions & 0 deletions charts/best-practices-k8s/pols/add_ns_quota.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-ns-quota
annotations:
policies.kyverno.io/title: Add Quota
policies.kyverno.io/category: Multi-Tenancy, EKS Best Practices
policies.kyverno.io/subject: ResourceQuota, LimitRange
policies.kyverno.io/minversion: 1.6.0
policies.kyverno.io/description: >-
To better control the number of resources that can be created in a given
Namespace and provide default resource consumption limits for Pods,
ResourceQuota and LimitRange resources are recommended.
This policy will generate ResourceQuota and LimitRange resources when
a new Namespace is created.
spec:
rules:
- name: generate-resourcequota
match:
any:
- resources:
kinds:
- Namespace
generate:
apiVersion: v1
kind: ResourceQuota
name: default-resourcequota
synchronize: true
namespace: "{{request.object.metadata.name}}"
data:
spec:
hard:
requests.cpu: '4'
requests.memory: '16Gi'
limits.cpu: '4'
limits.memory: '16Gi'
- name: generate-limitrange
match:
any:
- resources:
kinds:
- Namespace
generate:
apiVersion: v1
kind: LimitRange
name: default-limitrange
synchronize: true
namespace: "{{request.object.metadata.name}}"
data:
spec:
limits:
- default:
cpu: 500m
memory: 1Gi
defaultRequest:
cpu: 200m
memory: 256Mi
type: Container
47 changes: 47 additions & 0 deletions charts/best-practices-k8s/pols/add_rolebinding.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-rolebinding
annotations:
policies.kyverno.io/title: Add RoleBinding
policies.kyverno.io/category: Multi-Tenancy
policies.kyverno.io/subject: RoleBinding
policies.kyverno.io/minversion: 1.6.0
policies.kyverno.io/description: >-
Typically in multi-tenancy and other use cases, when a new Namespace is created,
users and other principals must be given some permissions to create and interact
with resources in the Namespace. Very commonly, Roles and RoleBindings are used to
grant permissions at the Namespace level. This policy generates a RoleBinding
called `<userName>-admin-binding` in the new Namespace which binds to the ClusterRole
`admin` as long as a `cluster-admin` did not create the Namespace. Additionally, an annotation
named `kyverno.io/user` is added to the RoleBinding recording the name of the user responsible
for the Namespace's creation.
spec:
background: false
rules:
- name: generate-admin-binding
match:
any:
- resources:
kinds:
- Namespace
exclude:
any:
- clusterRoles:
- cluster-admin
generate:
synchronize: true
kind: RoleBinding
name: "{{request.userInfo.username}}-admin-binding"
namespace: "{{request.object.metadata.name}}"
data:
metadata:
annotations:
kyverno.io/user: "{{request.userInfo.username}}"
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- kind: User
name: "{{request.userInfo.username}}"
41 changes: 41 additions & 0 deletions charts/best-practices-k8s/pols/add_safe_to_evict.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-safe-to-evict
annotations:
policies.kyverno.io/category: Other
policies.kyverno.io/subject: Pod,Annotation
policies.kyverno.io/minversion: 1.4.3
policies.kyverno.io/description: >-
The Kubernetes cluster autoscaler does not evict pods that
use hostPath or emptyDir volumes. To allow eviction of these pods, the annotation
cluster-autoscaler.kubernetes.io/safe-to-evict=true must be added to the pods.
spec:
rules:
- name: annotate-empty-dir
match:
resources:
kinds:
- Pod
mutate:
patchStrategicMerge:
metadata:
annotations:
+(cluster-autoscaler.kubernetes.io/safe-to-evict): "true"
spec:
volumes:
- <(emptyDir): {}
- name: annotate-host-path
match:
resources:
kinds:
- Pod
mutate:
patchStrategicMerge:
metadata:
annotations:
+(cluster-autoscaler.kubernetes.io/safe-to-evict): "true"
spec:
volumes:
- hostPath:
<(path): "*"
Loading

0 comments on commit 859fca8

Please sign in to comment.