← 输入框|github.com|刷新
Skip to content

SCB Scan creation does not seem to work properly within a OVH Cluster  #663

Closed

Description

@ineluki00

🐞 Bug report

Hi,

i have installed the securecodebox operator and a zaproxy + generic webhook on an AWS cluster and it works great.
But i have made the exact same installation procedure on an OVH cluster, everything seems ok in installation logs, CRDs are present, operator and minio pods in securecodebox-system namespace too. But when i try to launch a scan, i can see the log trace:

scan.execution.securecodebox.io/zap-baseline-scan-xxx created

and a new line in kubectl get scans but with a state staying empty and no new job created for this new scan....

Did anyone encountered this problem before ? Is there something to check somewhere in the cluster configuration ? How can i test that the controller responsible for crd creation is operational with enough access rights ?

For information i am using helm v3.3.3 on a kubernetes v1.20.2 cluster.

Thanks in advance.

Activity

  1. J12934 commented on Sep 21, 2021

    @J12934
    Member

    Hey, yeah if the state stays empty that pretty likely because the operator isn't running correctly.

    Can you see if the operator is running and check the logs?

    kubectl --namespace securecodebox-system get pods
    kubectl --namespace securecodebox-system logs deployment/securecodebox-controller-manager
  2. changed the title [-]Scan creation does not create job...[/-] [+]SCB Scan creation does not seem to work properly within a OVH Cluster [/+] on Sep 22, 2021
  3. ineluki00 commented on Sep 22, 2021

    @ineluki00
    Author

    Hi,

    effectively it seems that securecodebox-operator service account does not have access to configmaps...

    leaderelection.go:325] error retrieving resource lock securecodebox-system/xxxxxxxx.securecodebox.io: configmaps "xxxxxxxxxx.securecodebox.io" is forbidden: User "system:serviceaccount:securecodebox-system:securecodebox-operator" cannot get resource "configmaps" in API group "" in the namespace "securecodebox-system"

    From what i can see, the 'manager-rolebinding' ClusterRoleBinding is present and the related 'manager-role' ClusterRole too but the ClusterRole does not specify any configmaps resource. But when i add it to 'manager-role'

    - apiGroups:
      - ""
      resources:
      - pods
      - configmaps <-- +
      verbs:
      - get

    and redeploy securecodebox-controller-manager i get another error:

    leaderelection.go:329] error initially creating leader election record: configmaps is forbidden: User "system:serviceaccount:securecodebox-system:securecodebox-operator" cannot create resource "configmaps in API group "" in the namespace "securecodebox-system"

    So i moved previously added line to another block with create verb and then i got another error:

    leaderelection.go:325] error retrieving resource lock securecodebox-system/xxxxxxx.securecodebox.io: leases.coordination.k8s.io "xxxxxxx.securecodebox.io" is forbidden: User "system.serviceaccount:securecodebox-operator" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "securecodebox-system"

    It seems like if the 'leader-election-role' content was not linked with the controller while it is present...
    Is there a problem with multiple configmaps load ?
    I could try to merge leader-election-role in manager-role but it would make a non-sense...

    Thanks in advance

  4. J12934 commented on Sep 22, 2021

    @J12934
    Member

    Hi thank you for the extensive investigation 👍

    I'm still not sure why this is making issues in this cluster, the leader-election-role is usually bound to the scb operator service account using the RoleBinding here: https://github.com/secureCodeBox/secureCodeBox/blob/main/operator/templates/rbac/leader_election_role_binding.yaml

    Is that rolebinding not present in the cluster, or just not working correctly?
    If it is present, but not working correctly is there a way to update the cluster to a newer 1.20 patch release? Just to make sure it isn't an actual bug in Kubernetes (even thought it's probably unlikely).

  5. J12934 commented on Jan 14, 2022

    @J12934
    Member

    Closing this now.
    If you have found a solution or have more info to debug this further feel free to reopen 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugBugsquestionFurther information is requested

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions