I did something similar with a reverse proxy. The proxy embeds the token in
the request to openshift.

On Fri, Feb 8, 2019, 9:30 AM Gabe Montero <[email protected] wrote:

> You need to provide a bearer token with sufficient permissions to all the
> OpenShift project(s) involved.
>
> A quick example on how to get such a token is at
> https://github.com/openshift/jenkins-openshift-login-plugin#non-browser-access
> Apply what is done for the example curl invocation to the webhook
> config/invocation.
>
> And remember if your flow is spanning multiple projects, you'll need an SA
> with sufficient roles/permissions to each of those projects.
>
> On Fri, Feb 8, 2019 at 1:24 AM Samuel Martín Moro <[email protected]>
> wrote:
>
>> Hi,
>>
>> Using the generic webhook trigger plugin myself, while still relying on
>> OpenShift authentication logging into Jenkins, I don't remember having
>> anything like this.
>> Although I can't explain why your plugin would refuse this, unless maybe
>> something's wrong in Jenkins permissions matrix?
>>
>> As far as I've seen, generic triggers from a BuildConfig wouldn't allow
>> for multi-branch jobs - or if they do, I'm still looking for a way to
>> retrieve the triggering branch as a variable somewhere (note: that ruddra
>> sample shows the buildconfig has a "ref: master", which would suggest it is
>> not multi-branch capable).
>> So far, Jenkins plugins was my next best solution, although not ideal.
>>
>>
>> Anyway, you might be able to create a role - or clusterrole - and
>> corresponding binding, with something like this (not tested)
>>
>> - apiVersion: rbac.authorization.k8s.io/v1
>>   kind: ClusterRole
>>   metadata:
>>     name: bitbucket-jenkins-hook
>>   rules:
>>   - nonResourceURLs: [ "/bitbucket-scmsource-hook/*" ]
>>     verbs: [ "get", "post" ]
>>
>> - apiVersion: rbac.authorization.k8s.io/v1
>>   kind: ClusterRoleBinding
>>   metadata:
>>     name: bitbucket-jenkins-hook
>>   roleRef:
>>     apiGroup: rbac.authorization.k8s.io
>>     kind: ClusterRole
>>     name: bitbucket-jenkins-hook
>>   subjects:
>>   - apiGroup: rbac.authorization.k8s.io
>>     kind: Group
>>     name: system:unauthenticated
>>   - apiGroup: rbac.authorization.k8s.io
>>     kind: Group
>>     name: system:authenticated
>>
>> (see: https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
>>
>>
>>
>> On Fri, Feb 8, 2019 at 7:14 AM Graham Dumpleton <[email protected]>
>> wrote:
>>
>>> I believe you should be using the web book URL from the pipeline build
>>> config.
>>>
>>> You can get them from the web console page for the pipeline.
>>>
>>> See:
>>>
>>> *
>>> https://ruddra.com/posts/openshift-python-gunicorn-nginx-jenkins-pipelines-part-three/
>>>
>>> Graham
>>>
>>> On 8 Feb 2019, at 5:03 pm, Sean Dawson <[email protected]>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I have Jenkins running in an OpenShift cluster and I have a multi
>>> branch job set up, with the source git repository residing in
>>> Bitbucket server.
>>>
>>> I wan't to set up a web hook from Bitbucket Server to Jenkins to
>>> trigger builds as soon as there are changes to the repo. In a vanilla
>>> Jenkins installation you are able to simply post the updates to
>>> "${JENKINS_URL}/bitbucket-scmsource-hook/notify" as mentioned in this
>>> article:
>>>
>>>
>>> https://support.cloudbees.com/hc/en-us/articles/115000053051-How-to-Trigger-Multibranch-Jobs-from-Bitbucket-Server-#configurationinbitbucketserver
>>>
>>> However, our Jenkins instance is the OpenShift version and uses
>>> OpenShift to authenticate. When I try to post to this URL I get the
>>> following error:
>>>
>>>    {
>>>    "kind": "Status",
>>>    "apiVersion": "v1",
>>>    "metadata": {
>>>
>>>    },
>>>    "status": "Failure",
>>>    "message": "forbidden: User \"system:anonymous\" cannot post path
>>> \"/bitbucket-scmsource-hook/notify\": no RBAC policy matched",
>>>    "reason": "Forbidden",
>>>    "details": {
>>>
>>>    },
>>>    "code": 403
>>>    }
>>>
>>> Does anyone know of a way to allow the "system:anonymous" user to post
>>> to that path?
>>>
>>> Thanks
>>>
>>> Sean
>>>
>>> _______________________________________________
>>> users mailing list
>>> [email protected]
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> [email protected]
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>
>>
>>
>> --
>> Samuel Martín Moro
>> {EPITECH.} 2011
>>
>> "Nobody wants to say how this works.
>>  Maybe nobody knows ..."
>>                       Xorg.conf(5)
>> _______________________________________________
>> users mailing list
>> [email protected]
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to