Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default security context settings for SpiceDB Clusters #236

Open
jawnsy opened this issue Aug 16, 2023 · 1 comment
Open

Default security context settings for SpiceDB Clusters #236

jawnsy opened this issue Aug 16, 2023 · 1 comment
Labels
area/security Affects security priority/3 low This would be nice to have

Comments

@jawnsy
Copy link
Contributor

jawnsy commented Aug 16, 2023

Summary

Add default pod and container security context settings.

Background

At the moment, the operator creates a deployment without any security context settings, so will use the cluster defaults. SpiceDB is relatively low risk because it's not an external-facing service, but it would still be helpful to add some more restrictive defaults, because some clusters have admission controllers that enforce more restrictive policies (tools like Kyverno, OPA Gatekeeper, or OpenShift)

The deployment currently looks like this in our cluster (some irrelevant data removed to highlight the securityContext):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spicedb-spicedb
  namespace: spicedb
spec:
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/instance: spicedb-spicedb
  template:
    metadata:
      labels:
        app.kubernetes.io/instance: spicedb-spicedb
        authzed.com/cluster: spicedb
        authzed.com/cluster-component: spicedb
        authzed.com/managed-by: operator
    spec:
      containers:
        - command:
            - spicedb
            - serve
          image: ghcr.io/authzed/spicedb:v1.23.1
          name: spicedb
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: spicedb
      serviceAccountName: spicedb
      terminationGracePeriodSeconds: 30

Adding some default pod and container security context settings would be useful:

  • runAsNonRoot
  • readOnlyRootFilesystem
  • Drop capabilities
  • Use default seccomp profile

Workaround

Users can apply this manually using patches, but it's preferable to have hardened defaults, especially because the SpiceDB maintainers have a better sense of the constraints that would work for you.

@jawnsy jawnsy changed the title Default security context settings Default security context settings for SpiceDB Clusters Aug 16, 2023
@jzelinskie jzelinskie added area/security Affects security priority/3 low This would be nice to have labels Aug 16, 2023
@jawnsy
Copy link
Contributor Author

jawnsy commented Aug 20, 2023

In case this is useful for anyone else, this can be applied using patches as follows:

---
apiVersion: authzed.com/v1alpha1
kind: SpiceDBCluster
metadata:
  name: spicedb
spec:
  channel: stable
  config:
    datastoreEngine: postgres
    logLevel: info
    replicas: 3
    serviceAccountName: spicedb
  patches:
    - kind: Deployment
      patch:
        op: replace
        path: /spec/template/spec/securityContext
        value:
          runAsUser: 65532
          runAsGroup: 65532
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault
    - kind: Deployment
      patch:
        op: add
        path: /spec/template/spec/containers/0/securityContext
        value:
          runAsUser: 65532
          runAsGroup: 65532
          runAsNonRoot: true
          readOnlyRootFilesystem: true
          seccompProfile:
            type: RuntimeDefault
          allowPrivilegeEscalation: false
          capabilities:
            drop:
              - ALL
  secretName: spicedb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security Affects security priority/3 low This would be nice to have
Projects
None yet
Development

No branches or pull requests

2 participants