schemahero / schemahero-helm

A Helm chart for SchemaHero

What is SchemaHero?

SchemaHero is a Kubernetes Operator for Declarative Schema Management for various databases. SchemaHero has the following goals:

1. Database table schemas can be expressed as Kubernetes resources that can be deployed to a cluster.
2. Database schemas can be edited and deployed to the cluster. SchemaHero will calculate the required change (ALTER TABLE statement) and apply it.
3. SchemaHero can manage databases that are deployed to the cluster, or external to the cluster (RDS, Google CloudSQL, etc).

Getting Started

The recommended way to deploy SchemaHero is to use the kubectl plugin. Full instruction and other installation methods listed in the documentation.

To get started, read the tutorial and the full documentation

Community

For questions about using SchemaHero, there's a Replicated Community forum, and a #schemahero channel in Kubernetes Slack. If you are interested in contributing to Schemahero, you can find more information on how to get started on our Community page.

If you're a user of SchemaHero, add yourself to the ADOPTERS file!

schemahero-helm's Issues

CRDs are not in sync, update from schemahero

Update CRDs from https://github.com/schemahero/schemahero/tree/main/config/crds/v1

Image is tightly coupled to Chart.AppVersion

Image is tightly coupled to Chart.AppVersion

image: {{ .Values.registry }}schemahero/schemahero-manager:{{ .Chart.AppVersion }}

The AppVersion should be given a default value, which can be optionally replaced by a tag defined in values.yaml.

image: {{ .Values.registry }}schemahero/schemahero-manager:{{ .Values.image.tag | default .Chart.AppVersion }}

Update template for specifying extraArgs

Currently, extraArgs has to be specified in a 'nonstandard' way otherwise we get an error

helm template .
Error: YAML parse error on schemahero/templates/manager.yaml: error converting YAML to JSON: yaml: line 37: could not find expected ':'

currently:
extraArgs: ['- --log-level', '- debug']

expected:
extraArgs: ['--log-level', 'debug']

[BUG] StatefulSet schemahero has too much RBAC permission which may leads the whole cluster being hijacked

Hi community! Our team just found a possible security issue when reading the code. We would like to discuss whether it is a real vulnerability.

Description

The bug is that the StatefulSet schemahero in the charts has too much RBAC permission than it needs, which may cause some security problems, and the worse one leads cluster being hijacked. The problem is that the schemahero doesn't specify a ServiceAccount, so it uses the default ServiceAccount, which is bound to a clusterrole(cluster-role.yaml#L4) with the following sensitive permissions:

• create/patch/update verb of the deployments resource (ClusterRole)
• patch verb of the statefulsets resource (ClusterRole)

After reading the source code of schemahero, I didn't find any Kubernetes API usages using these permissions. However, these unused permissions may have some potential risks:

• create/patch/update verb of the deployments resource
  • A malicious user can create a privileged container with a malicious container image capable of container escape. This would allow him/she gaining ROOT privilege of the worker node the created container deployed. Since the malicious user can control the pod scheduling parameters (e.g., replicas number, node affinity, …), he/she should be able to deploy the malicious container to every (or almost every) worker node. This means the malicious user will be able to control every (or almost every) worker node in the cluster.
  • The other permissions of deployments/statefulsets also share the same risks.

The malicious users only need to get the service account token to perform the above attacks. There are several ways have already been reported in the real world to achieve this:

• Supply chain attacks: Like the xz backdoor in the recent. The attacker only needs to read /var/run/secrets/kubernetes.io/serviceaccount/token.
• RCE vulnerability in the APP: Any remote-code-execution vulnerability that can read local files can achieve this.

Mitigation Suggestion

• Remove all the unnecessary permissions
• Write Kyverno or OPA/Gatekeeper policy to:
  • Limit the container image, entrypoint and commands of newly created pods. This would effectively avoid the creation of malicious containers.
  • Restrict the securityContext of newly created pods, especially enforcing the securityContext.privileged and securityContext.allowPrivilegeEscalation to false. This would prevent the attacker from escaping the malicious container. In old Kubernetes versions, PodSecurityPolicy can also be used to achive this (it is deprecated in v1.21).

Few Questions

• Are these permissions really unused for schemahero?
• Would these mitigation suggestions be applicable for the schemahero?
• Our team have also found other unneccessary permissions (which is not that sensitive as above, but could also cause some security issues). Please tell us if you are interested in it. We’ll be happy to share it or PR a fix.

References

Several CVEs had already been assigned in other projects for similar issues:

• 2023-30512
• 2023-30617
• 2023-26484
• 2023-30840