openshift/ansible-service-broker

need apiVersion 2 of ansible servcie broker

Opened this issue · 9 comments

This form is for bug reports and feature requests. Major features will go through a spec process.

Feature:

Bug:

What happened:

What you expected to happen:

How to reproduce it:

Feature: Registring ansible service broker to cloud foundry
Bug: Server error, status code: 502, error code: 10001, message: The service broker rejected the request to https://54.205.122.2:8443/v2/catalog. Status Code: 403 Forbidden, Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"forbidden: User "system:anonymous" cannot get path "/v2/catalog": User "system:anonymous" cannot "get" on "/v2/catalog"","reason":"Forbidden","details":{},"code":403}

What happened: so, On cloud foundry I have apiVersion is 2 but your ansible service broker works on api version 1, I am using this template https://github.com/openshift/ansible-service-broker/blob/master/templates/simple-broker-template.yaml

Expected to happen: want to register the ansible service broker on my cloud foundry.

"kind":"Status","apiVersion":"v1"

this refers to the apiVersion for the kind: Status of the Kubernetes API, https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/#componentstatus-v1-core for reference.

forbidden: User "system:anonymous" cannot get path "/v2/catalog": User "system:anonymous" cannot "get" on "/v2/catalog would prevent you from being able to register the ansible service broker with cloud foundry. Requests to the broker's catalog are authenticated, in the simple-broker-template the token found in ansibleservicebroker-client secret is needed to make authenticated requests. See this portion of the simple-broker-template to get an idea of how we provide authentication information to the service-catalog when we register a ClusterServiceBroker.

Feature: Registring ansible service broker to cloud foundry
Bug: Server error, status code: 502, error code: 10001, message: The service broker rejected the request to https://54.205.122.2:8443/v2/catalog. Status Code: 403 Forbidden, Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"forbidden: User "system:anonymous" cannot get path "/v2/catalog": User "system:anonymous" cannot "get" on "/v2/catalog"","reason":"Forbidden","details":{},"code":403}

What happened: so, On cloud foundry I have apiVersion is 2 but your ansible service broker works on api version 1 , Link

"kind":"Status","apiVersion":"v1"

this refers to the apiVersion for the kind: Status of the Kubernetes API, https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/#componentstatus-v1-core for reference.

forbidden: User "system:anonymous" cannot get path "/v2/catalog": User "system:anonymous" cannot "get" on "/v2/catalog would prevent you from being able to register the ansible service broker with cloud foundry. Requests to the broker's catalog are authenticated, in the simple-broker-template the token found in ansibleservicebroker-client secret is needed to make authenticated requests. See this portion of the simple-broker-template to get an idea of how we provide authentication information to the service-catalog when we register a ClusterServiceBroker.

I am not understanding that how to do the authentication.
so I am explaining what I have done till now.
I have installed ansible service broker on openshift on single centos VM using this link
https://blog.openshift.com/up-and-running-with-the-openshift-ansible-broker/

versions detail:
[root@ip-10-1-100-242 centos]# oc version
oc v3.9.0+191fece
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://54.205.122.2:8443

openshift v3.9.0+71543b2-33
kubernetes v1.9.1+a0ce1bc657

Then I tried registering the ansible service broker on cf using the command
on cloudfoundry CLI
cf create-service-broker ansible-service-broker admin admin https://54.205.122.2:8443

after this command, I am getting the issue which I mentioned earlier comment. After this I dont know where to do the authentication and what will be username and password or token for authentication.

@lordcf we've never formally tested the broker with Cloud Foundry. I believe you'll need to configure the broker to use Basic Auth so it will work with Cloud Foundry. Set auth.type to basic and auth.enabled to true. The simple template has it set to false:

auth:
          - type: basic
            enabled: false

The following document https://github.com/openshift/ansible-service-broker/blob/master/docs/auth.md explains how t o configure basic auth. The mechanism is simple, determine a username & password combination you want. Then on the OpenShift side where the broker lives, you create a secret with the username and password. Then in Cloud Foundry you need to configure it to use the same username & password combination when talking to the broker. This should fix the authentication problem between the two.

@lordcf I'm unsure of the use case you are working towards but wanted you to be aware that I don't believe our broker will run as-is on cloud foundry, even if you work through issues with the broker booting up and registering to the service catalog.

My concerns are around running service-bundles, we rely on k8s api's to create a pod and run a bundle. That portion of the broker will need updates to use a new mechanism for running a container to execute work if this is to run exclusively on cloud foundry.

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

/close

@jmrodri: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.