awslabs/aws-servicebroker

AWS Service Broker

aws-servicebroker's Issues

Ability to use a custom parameter group

the problem:

Customising a few databases parameters through parameter group.

Solution we'd like:

It'll be great if we can configure a custom parameter group.

e.g.

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: rdspostgresql-dev
spec:
  clusterServiceClassExternalName: rdspostgresql
  clusterServicePlanExternalName: dev
  parameters:
    AccessCidr: 172.20.0.0/16
    EngineVersion: 9.6.3
    PostgresServerTimezone: UTC
    PubliclyAccessible: false
    DBInstanceClass: db.t2.small
    DBParameterGroupName: <custom_parameter_group_name>

Alternatives:

Change parameter group after create RDS.

Helm-Documentation is missing mentioning "ClusterServiceBroker"

Describe the bug
I'm unable to install aws-servicebroker with the provided helm documentation

To Reproduce
Assuming helm and tiller is already installed:

1. helm repo add aws-sb https://awsservicebroker.s3.amazonaws.com/charts
2. helm install aws-sb/aws-servicebroker --name aws-servicebroker --namespace aws-sb --version 1.0.0-beta.2
3. Errormessage appears:

Error: validation failed: unable to recognize "": no matches for kind "ClusterServiceBroker" in version "servicecatalog.k8s.io/v1beta1"

Expected behavior
Helm successfully deploys the servicebroker

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• Application Platform: Kubernetes
• Application Platform Version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.1", GitCommit:"4ed3216f3ec431b140b1d899130a69fc671678f4", GitTreeState:"archive", BuildDate:"2018-10-07T09:55:32Z", GoVersion:"go1.11", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.8", GitCommit:"7eab6a49736cc7b01869a15f9f05dc5b49efb9fc", GitTreeState:"clean", BuildDate:"2018-09-14T15:54:20Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

• Broker Version 1.0.0-beta.2
  Additional context
  Kubernetes deployed via kops on AWS.

Service Request: Elasticsearch

Support for AWS Elasticsearch Service would help with bootstrapping logging infrastructure in new clusters.

[k8s] container creation fails with psp on provision instance

When creating my first servicebinding (s3), the service broker creates a namespace dh-s3-prov- and try to start the s3 provider pod.
I have pod security policies in place to not allow run as root so this fails with the error:

Error: container has runAsNonRoot and image has non-numeric user (apb), cannot verify user is non-root

Since the service broker adds a random id to the namespace name I cannot put a psp in place to allow run as root for this specific namespace (and of course I don't want to do this in non-testing environments).
Maybe it would be a solution to replace the user in the Dockerfiles with the numeric id of the apb user to avoid this issue.
I guess I'm not the only one who wants to avoid root containers in a kubernetes cluster?

Give option to be compatible with Spring Cloud Connectors and other libraries

Is your feature request related to a problem? Please describe.

Existing libraries expect certain names for bound credentials, such as Url.

Currently these are converted to SCREAMING_SNAKE_CASE (e.g. URL) and thus fail to be recognised.

Describe the solution you'd like

Give the ability for a template to specify that this conversion should not take place.

Describe alternatives you've considered

File bugs against all existing libraries to perform case insensitive comparisions.

Additional context

None.

Credentials for provisioning ServiceInstances doesn't appear to default to what is used for broker operations.

Describe the bug

According to the install_prereqs.md document:

"By default the broker will use the same credentials for provisioning ServiceInstances and for broker operations like fetching the catalog and reading/writing metadata to DynamoDB."

But I don't believe I am seeing that behavior. I have a role assigned to the k8s node that the broker is running on (with the required IAM policies as instructed in the documentation). This allows the broker to start-up, fetch catalog, etc.

Start-up Log:

I0925 21:13:40.225027 1 util.go:212] Did not find 'aws_access_key' and 'aws_secret_key' in params, using default chain. I0925 21:13:40.225091 1 aws_sdk.go:63] Parameter 'target_role_name' not set. Not assuming role. I0925 21:13:40.225117 1 util.go:212] Did not find 'aws_access_key' and 'aws_secret_key' in params, using default chain. I0925 21:13:40.225131 1 aws_sdk.go:63] Parameter 'target_role_name' not set. Not assuming role. I0925 21:13:40.634674 1 awsbroker.go:38] Running as caller identity '{ Account: "755621335444", Arn: "arn:aws:sts::XXXXXX:assumed-role/k8s-dev-node-20180917031935213600000001/i-0f3d92fd704eb2cfe", UserId: "AROAJWLLVCXBHEGTXKLMK:i-0f3d92fd704eb2cfe" }'.

However when I go to provision a SerivceInstance it errors stating that aws_access_key and aws_secret_key can not be blank. I then have to deploy the chart specifying aws.accesskeyid and aws.secretkey.

To Reproduce

Install official helm chart:helm install aws-sb/aws-servicebroker --name aws-servicebroker --namespace aws-sb --version 1.0.0-beta --set aws.region=us-west-2 --set aws.vpcid=vpc-XXXXX

And leave out the aws.accesskeyid and aws.secretkey.

Expected behavior

As per the documentation the serviceinstance provisioning should default to the same credentials as the broker.

Environment (please complete the following information):

• Application Platform:k8s
• Application Platform Version: v1.10.5
• Broker Version 1.0.0-beta

move to xenial trusty is going to be eol

the pivotal tile currently requires a trusty stemcell
as trusty is going to be end of life soon and it should be really easy to move to xenial

Allow Custom Tags to be Added to Provisioned Resources

Many Enterprises use custom tags on AWS Resources for a number of different purposes e.g. internal billing, access control etc.

It would be nice to be able specify custom tags to be added to resources when provisioning.

A blanket set of additional tags would be a great start but it would be nice to be able to have different tags with a namespace / project. Taking this further you could set the base tags in the broker and add additional tags, or override tag values at the project level.

Deploy on AWS

Hey there, we would like to deploy the AWS ServiceBroker on AWS :) From the documentation this is not a supported way of providing that yet. Do you see any chance that we can accomplish this? And if so, could you give some advice on how to best approach this?

We are planning on running Cloud Foundry on AWS and would like to allow platform users to easily take advantage of native AWS resources through this service broker.

Using assumed role appears to be broken

Describe the bug
The docs says that it's possible to use an assumed role by providing the target_account_id and target_role_name configuration values.

To Reproduce
Create a service broker with target_account_id and target_role_name parameters

Expected behavior
The resource are created with the given role.

Actual behavior
The service creation request is rejected, with The parameter target_account_id is not available.

Environment (please complete the following information):

• Cloud Foundry on Kubernetes (SCF)
• Broker commit 100cc6b

Additional context
AwsBroker.Provision rejects requests with unknown parameters; it does not check nonCfnParams (where the role stuff is).

Missing 'clusterid' in context

Describe the bug
When I create a ServiceInstance (e.g. S3) the AWS service broker panics:

I1113 12:12:55.900058       1 awsbroker.go:239] Client OSB API Version: "2.13"
I1113 12:12:55.900164       1 apisurface.go:89] Received ProvisionRequest for instanceID "c58bb5e8-1318-4dab-b02d-ec551158f200"
I1113 12:12:55.900194       1 api.go:54] request={InstanceID:c58bb5e8-1318-4dab-b02d-ec551158f200 AcceptsIncomplete:true ServiceID:0d7d708a-006e-5d0b-a151-264c90a1599c PlanID:33d9dd5d-fc6d-5a09-9e25-485cc5e05eb4 OrganizationGUID:63ac6aa8-e72e-11e8-b440-028d5585b360 SpaceGUID:63ac6aa8-e72e-11e8-b440-028d5585b360 Parameters:map[GlacierLifeCycleTransitionInDays:0 LifeCyclePrefix:Archive LoggingPrefix:Archive BucketAccessControl:Private BucketName:Auto EnableGlacierLifeCycle:False EnableLogging:True EnableVersioning:False] Context:map[namespace:srueg-test platform:kubernetes] OriginatingIdentity:0xc00049c600}
2018/11/13 12:12:55 http: panic serving 10.1.2.59:54002: interface conversion: interface {} is nil, not string
goroutine 5815 [running]:
net/http.(*conn).serve.func1(0xc00056a320)
	/usr/local/go/src/net/http/server.go:1746 +0xd0
panic(0xc38180, 0xc000681c20)
	/usr/local/go/src/runtime/panic.go:513 +0x1b9
github.com/awslabs/aws-servicebroker/pkg/broker.getCluster(0xc000681b90, 0xd4bab4, 0xb)
	/go/src/github.com/awslabs/aws-servicebroker/pkg/broker/util.go:296 +0x22d
github.com/awslabs/aws-servicebroker/pkg/broker.(*AwsBroker).Provision(0xc000166000, 0xc000174380, 0xc00049c620, 0xc0005c5bc0, 0x1, 0x1)
	/go/src/github.com/awslabs/aws-servicebroker/pkg/broker/api.go:61 +0xee
github.com/awslabs/aws-servicebroker/vendor/github.com/pmorie/osb-broker-lib/pkg/rest.(*APISurface).ProvisionHandler(0xc000444140, 0xe349c0, 0xc00054a700, 0xc000264d00)
	/go/src/github.com/awslabs/aws-servicebroker/vendor/github.com/pmorie/osb-broker-lib/pkg/rest/apisurface.go:96 +0x1d1
github.com/awslabs/aws-servicebroker/vendor/github.com/pmorie/osb-broker-lib/pkg/rest.(*APISurface).ProvisionHandler-fm(0xe349c0, 0xc00054a700, 0xc000264d00)
	/go/src/github.com/awslabs/aws-servicebroker/vendor/github.com/jaymccon/osb-broker-lib/pkg/server/server.go:82 +0x48
net/http.HandlerFunc.ServeHTTP(0xc0002262b0, 0xe349c0, 0xc00054a700, 0xc000264d00)
	/usr/local/go/src/net/http/server.go:1964 +0x44
github.com/awslabs/aws-servicebroker/vendor/github.com/gorilla/mux.(*Router).ServeHTTP(0xc0004002a0, 0xe349c0, 0xc00054a700, 0xc000264d00)
	/go/src/github.com/awslabs/aws-servicebroker/vendor/github.com/gorilla/mux/mux.go:162 +0xf1
net/http.serverHandler.ServeHTTP(0xc00015a270, 0xe349c0, 0xc00054a700, 0xc000264b00)
	/usr/local/go/src/net/http/server.go:2741 +0xab
net/http.(*conn).serve(0xc00056a320, 0xe35140, 0xc0000a91c0)
	/usr/local/go/src/net/http/server.go:1847 +0x646
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:2851 +0x2f5

The error seems to be, that the context which is delivered with the provisioning request doesn't contain the clusterid filed: https://github.com/awslabs/aws-servicebroker/blob/release-v1.0.0-beta.3/pkg/broker/util.go#L273

To Reproduce
Steps to reproduce the behavior.

Expected behavior
The ServiceInstance gets provisioned successfully.

Environment (please complete the following information):

• Application Platform: OpenShift Container Platform v3.9
• Application Platform Version: k8s 1.9, OpenShift v3.9
• Broker Version: release-v1.0.0-beta.3

Additional context
It's a fresh installation and provisioning never worked.

remove aws_access_key and aws_secret_key from templates and nonCfnParams

Currently we're exposing 2 mechanisms for specifying an IAM identity to use for provisioning/binding. The option of providing hard-coded credentials to use was originally the only option for this. Now with the cross-account assume role option, I don't see any value in the hard-coded credentials.

Additionally, having both available introduces confusion in platforms that present a ui, as the options are mutually exclusive and there is no guidance on precedence should a user provide both.

@vsomayaji are there any use-cases you can think of that would warrant keeping these ?

OCP Deployment Issues (cased by non base64 encoded secrets)

Describe the bug
A clear and concise description of what the bug is.

When you go to run the deploy.sh script the pod that gets deploye will error with the following message:

oom score for ready process caused \"write /proc/PID/oom_score_adj: invalid argument\""

These errors are a read harring for users (see below) as the error does not relate to the issue the user is facing.

kubernetes/kubernetes#30861
https://bugzilla.redhat.com/show_bug.cgi?id=1460097

To Reproduce
In an OCP cluster run the deploy.sh script.

Expected behavior

This should not error with this message, as the error is caused by the deployment secret (aws-servicebroker-credentials) should be base64 encoded for the end user (by running the scritp).

You know this is an error with the aws-servicebroker-credentials secrete because attempting to edit it, causes it to fail (in reading what is in the

$ oc edit secret aws-servicebroker-credentials 
error: secrets "aws-servicebroker-credentials" could not be patched: error decoding from json: illegal base64 data at input byte 52

Environment (please complete the following information):

• Application Platform: OpenShift
• Application Platform Version: 3.10
• Broker Version: Unclear

Additional context
What eventually worked to fix the issue was encoding the secret like so (note the -n on the echo cmd), where [AAAA...] is an AWS key:

$ echo -n AAAAAAAAAAAAAAA | base64 # access key encode
QUFBQUFBQUFBQUFBQUFB

echo -n ABCDEFGHIJKLMNOPQRSTUVWXYZ | base64 # secret key encode
QUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVo=

You then need to run oc replace -f /tmp/aws-servicebroker-credentials .yaml to try this update again, this assumes you ran: oc get secret aws-servicebroker-credentials -o yaml > /tmp/aws-servicebroker-credentials, where you replace the accesskeyid and secretkey of the secret with the values from above.

Surround the encoded AWS keys in single-quotes when adding them to the OpenShift secret 'aws-servicebroker-credentials', is important.

Example:

apiVersion: v1
data:
  accesskeyid: 'AAAAAAAAAAAAAAA'
  secretkey: 'QUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVo='

Constant "TLS handshake error" output in the logs

Describe the bug

Deployed into Kubernetes with the helm chart, I get one of these every 10 seconds:

2018/11/21 16:11:19 http: TLS handshake error from 10.192.3.171:41534: EOF

To Reproduce
Just view the logs.

Expected behavior
Not spamming errors.

Environment (please complete the following information):

• Application Platform: Kubernetes
• Application Platform Version: k8s 1.9.3
• Broker Version: 1.0.0-beta.3

What is the difference between OpenShift and Kubernetes deployment

After reading a lot, it seems that the difference is that the k8s way will use cloud formation, and the OS way will use these apb docker images that will use cloud formation at the end.

I just want to be sure that both methods will boil down to the same architecture, and that we'll have the same level of support for both.

Thanks for your help!

PS: if there is a better way to ask those questions, I'd be happy to use!

`bosh-release` repo is not a proper submodule, causes issues on recursive clone

Describe the bug
There is a bosh-release directory that holds a reference to a aws-servicebroker-boshrelease sub-repository that is not a submodule (there's no .gitmodules file at the top level).

To Reproduce

$ git submodule update --init --recursive
fatal: No url found for submodule path 'bosh-release/aws-servicebroker-boshrelease' in .gitmodules

Expected behavior
Either a valid submodule pointer, or no sub-repository in the tree.

Environment (please complete the following information):
master as of 100cc6b — no other configuration should be necessary.

Additional context
I can ignore the error on clone fine, it's just annoying because my CI system (amusingly from Pivotal) tries to recurse by default and falls splat on its face. Currently working around the issue by telling it to ignore all submodules, which works for now (but will break if there's an actual submodule we care about in the future).

Configurable CloudFormation stack name

Is your feature request related to a problem? Please describe.
I've been setting up a namespaced AWS Service Broker, but I'm seeing a lot of frustation in getting an overview in the AWS Console,
based on the naming-scheme for resources.
I see that the CloudFormation stack name is used, when no explicit name is set, which is ok.

Describe the solution you'd like
It would be nice to allow the CloudFormation stack name to be generated from the configured BrokerId in the config.

In a setup with namespaced service brokers, it gives a clean overview in AWS Console when resource-names are not specificed explicitly in the specifications.

Describe alternatives you've considered
I've considered changing all CloudFormation templates, but would love to stick with the public templates, as long as possible.

Additional context

Provisioning RDS Mysql using aws-servicebrokier giving issue

Hi All,

We have used following Kubernetes service yml file to provision AWS RDS Mysql, through the AWS service broker running on a kubernetes cluster (1.9) hosted on EC2.

service.yml.txt

We then run into the following error:

TASK [aws-provision-apb : Create Resources] ************************************
fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "An error occurred (ValidationError) when calling the CreateStack operation: Parameters: [DatabaseUsername, DatabasePassword] must have values An error occurred (ValidationError) when calling the CreateStack operation: Parameters: [DatabaseUsername, DatabasePassword] must have values - <class 'botocore.exceptions.ClientError'>"}

Can you please help us with the above?

Is there a working example kubernetes service yaml where we provision and AWS RDS?

RDS - Create unique credentials on each binding

broker provides the master database credentials on bind. For security and compliance reasons, we need to create a new credential pair on each bind (and destroy it on unbind).

Availability as PCF tile on pivnet?

Apologies for skipping the template, this doesn't quite fit the criteria--

We're under the impression this service broker will be available as a tile compatible with Pivotal's distribution of Cloud Foundry (PCF).

When do you think we'll see this available as a tile on Pivnet?

Failed to create resource. Not enough available space in the vpc

Describe the bug
Trying to create a RDS production instance, I get the following error:

Failed to create resource. Not enough available space in the vpc

Currently investigating. Created the issue to help other people.

[dynamodb] Can't change data type of primary key attributes

Describe the bug
The dynamodb class exposes parameters for changing the data type of the primary key attributes -- HashAttributeType and RangeAttributeType -- but they are not used. The data types are hardcoded to S:

aws-servicebroker/templates/dynamodb/template.yaml

Lines 116 to 122 in 9dd4f63

	AttributeDefinitions:
	-
	AttributeName: !Ref HashAttributeName
	AttributeType: "S"
	-
	AttributeName: !Ref RangeAttributeName
	AttributeType: "S"

Unable to set region for ServiceInstances

Describe the bug

I am installing the service broker into a k8s cluster via the provided helm chart as instructed in the documentation.

An inspect of the chart parameters shows value aws.region, which defaults to us-east-1. For my install I set to us-west-2 and the expectation was that ServiceInstances would be deployed in that region. That is not the case and they still get deployed into us-east-1.

To Reproduce

Install the broker via the official helm chart.

helm install aws-sb/aws-servicebroker --name aws-servicebroker --namespace aws-sb --version 1.0.0-beta --set aws.region=us-west-2 --set aws.accesskeyid=xxxxx --set aws.secretkey=xxxxxx --set aws.vpcid=vpc-XXXXX

Expected behavior

As there is no documentation that explains exactly what the values control I was operating under the assumption that the region defined the region for the ServiceInstances. If that is the case my expectation would be that Cloudformation stacks would be created in the region specified (us-west-2 in my case) not us-east-1.

Environment (please complete the following information):

• Application Platform: Kubernetes
• Application Platform Version: v1.10.5
• Broker Version: 1.0.0-beta

AWS Service Broker templates should be able to use Secrets for AWS credentials

What?

Running AWS Service Broker on OpenShift 3.10, the templates provided in the catalog requires manual input of AWS Access Key, AWS Secret Key, AWS CloudFormation Role ARN. These sensitive data could be stored and used through a Secret resource.

Why?

This would improve overall user experience, reducing complexity of deployments and fostering reusability across brokered services.

Fails to install in proxied environment

Hi, I have a couple of questions around deploying and then using AWS Service Broker

1. In this blog post it states allowing customers to leverage new features such as running behind proxy solutions. Is there any additional configuration required for this?

2. The APBs take the following parameter SBArtifactS3Bucket defaulted to awsservicebroker. Is this an existing bucket where config is read from, or a bucket where things are stored and therefore must pre-exist and the cluster (masters?) must have access permissions for?

Thanks

MasterUsername parameter not working for RDS MySQL

Describe the bug
When I attempt to provision an RDS MySQL instance it always fails with an error.

If I do not provide MasterUsername as a parameter, I see the error

34 util.go:288] Status: 500; ErrorMessage: <nil>; Description: Failed to create the CloudFormation stack: ValidationError: Parameters: [MasterUsername] must have values

If I provide MasterUsername as a parameter, I see the error:

34 util.go:288] Status: 400; ErrorMessage: <nil>; Description: The parameter MasterUsername is not available.; ResponseError: <nil>

To Reproduce

1. Using the Cloud Foundry CLI, run:
   cf create-service rdsmysql dev my-db -c '{"AccessCidr":"[REDACTED]", "VpcId":"[REDACTED]", "MasterUsername":"[REDACTED]"}'
   Result: Provisioning fails

Expected behavior
I would expect to be able to provide MasterUsername as a parameter when creating RDS MySQL because it is required.

Environment (please complete the following information):

• Application Platform: Cloud Foundry (Open Source)
• Application Platform Version: cf-deployment v4.1.0
• Broker Version: v1.0.0-beta

GetCatalog panics when a plan has no required params

Describe the bug
If a plan has no required params and prescribeOverrides is true, calling GetCatalog results in a panic.

To Reproduce
Upload a plan with no required params.

Expected behavior
No panic.

Environment (please complete the following information):

• Application Platform: Kubernetes
• Application Platform Version: k8s v1.10.6
• Broker Version: 1.0.0-beta.2

Additional context

2018/09/25 04:09:40 http: panic serving 100.123.178.131:42120: interface conversion: interface {} is nil, not []string
goroutine 134 [running]:
net/http.(*conn).serve.func1(0xc0003b5b80)
  /usr/local/go/src/net/http/server.go:1746 +0xd0
panic(0xc37f00, 0xc000517710)
  /usr/local/go/src/runtime/panic.go:513 +0x1b9
github.com/awslabs/aws-servicebroker/pkg/broker.prescribeOverrides(0x0, 0x0, 0x0, 0xc000394ed0, 0xc, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
  /go/src/github.com/awslabs/aws-servicebroker/pkg/broker/util.go:59 +0xa88
github.com/awslabs/aws-servicebroker/pkg/broker.(*AwsBroker).GetCatalog(0xc0000761a0, 0xc0003b0520, 0x4, 0x0, 0x0)
  /go/src/github.com/awslabs/aws-servicebroker/pkg/broker/api.go:42 +0x584
github.com/awslabs/aws-servicebroker/vendor/github.com/pmorie/osb-broker-lib/pkg/rest.(*APISurface).GetCatalogHandler(0xc0003bf7e0, 0xe33ea0, 0xc000384700, 0xc0001beb00)
  /go/src/github.com/awslabs/aws-servicebroker/vendor/github.com/pmorie/osb-broker-lib/pkg/rest/apisurface.go:63 +0x105
github.com/awslabs/aws-servicebroker/vendor/github.com/pmorie/osb-broker-lib/pkg/rest.(*APISurface).GetCatalogHandler-fm(0xe33ea0, 0xc000384700, 0xc0001beb00)
  /go/src/github.com/awslabs/aws-servicebroker/vendor/github.com/jaymccon/osb-broker-lib/pkg/server/server.go:80 +0x48
net/http.HandlerFunc.ServeHTTP(0xc000391b10, 0xe33ea0, 0xc000384700, 0xc0001beb00)
  /usr/local/go/src/net/http/server.go:1964 +0x44
github.com/awslabs/aws-servicebroker/vendor/github.com/gorilla/mux.(*Router).ServeHTTP(0xc00019f180, 0xe33ea0, 0xc000384700, 0xc0001beb00)
  /go/src/github.com/awslabs/aws-servicebroker/vendor/github.com/gorilla/mux/mux.go:162 +0xf1
net/http.serverHandler.ServeHTTP(0xc0001d3860, 0xe33ea0, 0xc000384700, 0xc0001be900)
  /usr/local/go/src/net/http/server.go:2741 +0xab
net/http.(*conn).serve(0xc0003b5b80, 0xe34620, 0xc0001ea380)
  /usr/local/go/src/net/http/server.go:1847 +0x646
created by net/http.(*Server).Serve
  /usr/local/go/src/net/http/server.go:2851 +0x2f5

No Images in Catalog

When deployed to OpenShift running on AWS I get the items in the Catalog but they have no images.

Any idea where to start to look into this?

OpenShift Master: v3.9.0+ba7faec-1
Kubernetes Master: v1.9.1+a0ce1bc657
OpenShift Web Console: v3.9.0+b600d46-dirty

Postgres RDS fails with missing MasterPassword

Describe the bug
I followed the tutorial from here:
https://aws.amazon.com/blogs/opensource/provision-aws-services-kubernetes-aws-service-broker/
I was able to provision a SQS, but on a Postgres RDS it always fails with:

TASK [aws-provision-apb : Encode bind credentials] *****************************
fatal: [localhost]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'dict object' has no attribute 'MasterPassword'\n\nThe error appears to have been in '/opt/ansible/roles/aws-provision-apb/tasks/main.yml': line 95, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n  when: create_iam_user == true\n- asb_encode_binding:\n  ^ here\n"}
 [WARNING]: Could not create retry file '/opt/apb/actions/provision.retry'.
[Errno 13] Permission denied: u'/opt/apb/actions/provision.retry'

PLAY RECAP *********************************************************************
localhost                  : ok=7    changed=2    unreachable=0    failed=1

To Reproduce
Followed the tutorial from
https://aws.amazon.com/blogs/opensource/provision-aws-services-kubernetes-aws-service-broker/

Modified the broker-config ConfigMap to include also the
- {apb_name: dh-rdspostgresql, secret: aws-secret, title: aws-secret}
This way I saw that the Postgres RDS ServiceInstance was able to use the aws-secret.

But no matter if I added the field:
MasterUserPassword: $n2w7dWbPDP3
or didn't use it at all I always got the same error.

This is the ServiceInstance I used:

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: dev-k8s-local-rds-postgresql
spec:
  clusterServiceClassExternalName: dh-rdspostgresql
  clusterServicePlanExternalName: dev
  parameters:
    AccessCidr: 172.20.0.0/16 # REQUIRED
    AllocatedStorageAndIops: 100 GB / 1,000 IOPS # OPTIONAL
    DBInstanceClass: db.t2.medium # OPTIONAL
    EngineVersion: 9.6.3 # OPTIONAL
    PostgresServerTimezone: UTC # OPTIONAL
    MasterUsername: postgres-rds-user
    MasterUserPassword: $n2w7dWbPDP3

Removing MasterUsername and MasterUserPassword leads to the same error.

Expected behavior

I should be able to create an Postgres RDS

Environment (please complete the following information):
Kubernetes Kops Cluster on AWS
Kubernetes version: 1.10.5

Add the ability to create databases in a existing instance

Is your feature request related to a problem? Please describe.
We currently deploy a RD instance with the service broker and get one database back. Our usecase needs multiple databases. Currently the service broker is not able to process such requests.

Describe the solution you'd like
Add a service which allows the use of the broker to create new databases in existing instances by providing the endpoint address, port and username/password

Describe alternatives you've considered
The alternative would use a terraform config inside a helm chart do create a user and database, grant access to the database and generating env variables for the container to pick up

S3 - support configuring different storage classes for S3

enable selceting a storage class for buckets

Integration with kube2iam - Bindings

The recommended way to access an RDS instance is to use an IAM role.
In k8s, it is possible using kube2iam.

Do you plan in supporting such setup?

Thanks for your help!

Helm install fails

Describe the bug
the installation with helm charts as described here fails when installing the broker

To Reproduce
Prereq: helm works

1. helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
2. helm repo update
3. helm install svc-cat/catalog --name catalog --namespace catalog
4. helm repo add aws-sb https://awsservicebroker.s3.amazonaws.com/charts
5. helm repo update
6. helm inspect aws-sb/aws-servicebroker fails with: Error: failed to download "aws-sb/aws-servicebroker" (hint: running helm repo update may help)
7. helm install aws-sb/aws-servicebroker -n aws-servicebroker --namespace aws-sb fails with Error: failed to download "aws-sb/aws-servicebroker" (hint: running helm repo update may help)

Info: helm search aws-servicebroker shows the chart though.

Expected behavior

helm should install the servicebroker

Screenshots
none

Environment (please complete the following information):

• Application Platform: kubernetes
• Application Platform Version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"archive", BuildDate:"2018-09-11T12:40:02Z", GoVersion:"go1.11", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.8", GitCommit:"c138b85178156011dc934c2c9f4837476876fb07", GitTreeState:"clean", BuildDate:"2018-05-21T18:53:18Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

• Broker Version /

Additional context

kubernetes deployed to aws with kops.

Description: Failed to create the CloudFormation stack:

Describe the bug
Trying to deploy a MySQL service.

Additional context
E1204 17:30:51.289739 1 util.go:269] Status: 500; ErrorMessage: ; Description: Failed to create the CloudFormation stack: AccessDenied: Access denied
status code: 403, request id: 5862fc30-f7ea-11e8-9bed-e94e95f61919; ResponseError:

I think I have an issue with the ServiceBroker role. Do you have hints on how to further investigate that?

thanks!

Updating a ServiceInstance for an RDS failed. Does it support updates?

Describe the bug
I tried to change the instance type of a Postgres RDS provision with a ServiceInstance from t2.medium to t2.large. The error that I got was:

Message:               ServiceBroker returned a failure for update call; update will not be retried: 
Status: 400; 
ErrorMessage: <nil>; 
Description: The service plan 6ad024ee-a01d-56d2-97f4-84bbdfabdcde has no updatable parameters.; 
ResponseError: <nil>

To Reproduce
Create a ServiceInstance for a Postgres RDS.
After provisioning is done, try to modify the instance type.
You will see you will receive an error. Another problem is you can't use that ServiceInstance anymore, after it failed no more ServiceBinding can be created.

Expected behavior
Update should be working, the changes should be propagated to the RDS instance, or I should not be allowed to modify the ServiceInstance.
I also realise this might be a feature request and not a bug.
I should still be able to create ServiceBinding even after the update failed because the RDS has no issues.

Environment (please complete the following information):
Kubernetes Kops Cluster on AWS
Kubernetes version: 1.10.5
Broker Version: 1.0.0-beta.2

RDS - Option to restore from existing snapshot on provision

Add a parameter to allow restoring from snapshot on provision.

x509: certificate signed by unknown authority

I was following along the Getting started on k8s guide, but I'm getting the following error

$ kubectl get clusterservicebrokers aws-service-broker -o yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ClusterServiceBroker
metadata:
  creationTimestamp: 2018-05-13T17:27:17Z
  finalizers:
  - kubernetes-incubator/service-catalog
  generation: 1
  name: aws-service-broker
  resourceVersion: "63"
  selfLink: /apis/servicecatalog.k8s.io/v1beta1/clusterservicebrokers/aws-service-broker
  uid: e21bfb76-56d2-11e8-a340-0242ac110005
spec:
  authInfo:
    bearer:
      secretRef:
        name: awsservicebroker-client-token-q85v9
        namespace: aws-service-broker
  caBundle: <REDACTED>
  relistBehavior: Duration
  relistDuration: 15m0s
  relistRequests: 0
  url: https://awssb.aws-service-broker.svc:1338/aws-service-broker/
status:
  conditions:
  - lastTransitionTime: 2018-05-13T17:27:17Z
    message: 'Error fetching catalog. Error getting broker catalog: Get https://awssb.aws-service-broker.svc:1338/aws-service-broker/v2/catalog:
      x509: certificate signed by unknown authority (possibly because of "crypto/rsa:
      verification error" while trying to verify candidate authority certificate "awssb.aws-service-broker.svc")'
    reason: ErrorFetchingCatalog
    status: "False"
    type: Ready
  operationStartTime: 2018-05-13T17:27:17Z
  reconciledGeneration: 0

Any ideas?

AWS servicebroker doesn't create classes/plans in service catalog

Describe the bug
I installed service-catalog and aws-broker but there are no classes/plans.
Maybe I did something wrong, but aws-broker seems to correctly publish its service th the catalog.

# svcat get broker
         NAME          NAMESPACE                                URL                                 STATUS
+--------------------+-----------+----------------------------------------------------------------+--------+
  aws-service-broker               https://aws-servicebroker.aws-service-broker.svc.cluster.local   Ready
# svcat describe broker aws-service-broker
  Name:     aws-service-broker
  URL:      https://aws-servicebroker.aws-service-broker.svc.cluster.local
  Status:   Ready - Successfully fetched catalog entries from broker @ 2018-10-05 14:02:51 +0000 UTC

But listing the classes/plans doesn't provide any output and a test serviceinstance give me a ReferencesNonexistentServiceClass

# svcat get plan
  NAME   CLASS   DESCRIPTION
+------+-------+-------------+
# svcat get classes
  NAME   NAMESPACE   DESCRIPTION
+------+-----------+-------------+
# svcat get instance
            NAME              NAMESPACE   CLASS    PLAN                 STATUS
+---------------------------+-----------+-------+--------+-----------------------------------+
  s3-custom-minimal-example   test-ns     dh-s3   custom   ReferencesNonexistentServiceClass

Although the logs of my aws-broker indicates, that it successfuly fetched the classes/plans from the official s3 bucket. The only strange thing here is a bunch of TLS handshake errors (IP is the worker IP where the aws-broker pod is running).

I1005 14:10:32.602453       1 awsbroker.go:205] Listing objects bucket: awsservicebroker region: us-east-1 prefix: templates/latest
I1005 14:10:33.048215       1 awsbroker.go:224] Found 12 objects
I1005 14:10:33.048308       1 awsbroker.go:199] Updating listings cache with [{/athena true} {/dynamodb true} {/elasticache true} {/emr true} {/kinesis true} {/kms true} {/lex true} {/polly true} {/rdsmariadb true} {/rdsmysql true} {/rdspostgresql true} {/redshift true} {/rekognition true} {/route53 true} {/s3 true} {/sns true} {/sqs true} {/translate true}]
I1005 14:10:33.177337       1 awsbroker.go:246] converting service definition "athena"
I1005 14:10:33.177474       1 awsbroker.go:364] done converting service definition "athena"
I1005 14:10:33.177508       1 adapter.go:35] putting service definition "athena" into dynamdb
I1005 14:10:33.384367       1 adapter.go:59] done putting service definition "athena" into dynamdb
[...]
I1005 14:10:36.010234       1 main.go:115] Starting broker!
I1005 14:10:36.014092       1 main.go:128] Starting secure broker with file based TLS cert and key
I1005 14:10:36.014122       1 server.go:138] Starting server on :3199
2018/10/05 14:10:48 http: TLS handshake error from 172.22.253.31:27476: EOF
2018/10/05 14:10:58 http: TLS handshake error from 172.22.253.31:27542: EOF
2018/10/05 14:11:08 http: TLS handshake error from 172.22.253.31:27598: EOF
[...]
2018/10/05 14:20:08 http: TLS handshake error from 172.22.253.31:31206: EOF
2018/10/05 14:20:18 http: TLS handshake error from 172.22.253.31:31282: EOF
2018/10/05 14:20:28 http: TLS handshake error from 172.22.253.31:31368: EOF
I1005 14:20:36.010604       1 awsbroker.go:205] Listing objects bucket: awsservicebroker region: us-east-1 prefix: templates/latest
I1005 14:20:36.486759       1 awsbroker.go:224] Found 12 objects
I1005 14:20:36.487027       1 awsbroker.go:199] Updating listings cache with [{/athena false} {/dynamodb false} {/elasticache false} {/emr false} {/kinesis false} {/kms false} {/lex false} {/polly false} {/rdsmariadb false} {/rdsmysql false} {/rdspostgresql false} {/redshift false} {/rekognition false} {/route53 false} {/s3 false} {/sns false} {/sqs false} {/translate false}]
2018/10/05 14:20:38 http: TLS handshake error from 172.22.253.31:31444: EOF
2018/10/05 14:20:48 http: TLS handshake error from 172.22.253.31:31520: EOF

I'm not sure if the TLS errors are related to my problem. But it is the only strange thing I can see in my setup.

To Reproduce
I just deployed the service-catalog and aws-broker from the helm charts (without tiller, though). I guess I'm missing something here, because the setup is pretty straight forward.

Expected behavior
The service catalog should fetch the classes and plans from the aws-broker.

Environment (please complete the following information):

• Application Platform: Kubernetes on-prem, CoreOS
• Application Platform Version: k8s 1.10.4
• Broker Version: 1.0.0-beta.2

Support MySQL 8.0

Is your feature request related to a problem? Please describe.
AWS RDS has added support for mysql 8.0. The service broker does not support this according to rdsmysql/template.yaml.

Describe the solution you'd like
It would be great if the service broker would add support for requesting mysql 8.0 instances.

Service Provisioning Fails

When I try to create a service like RDS MySQL, I'm running into the following issue:

[2018-07-18T17:47:06.923Z] [INFO] - ASYNC provisioning in progress
[2018-07-18T17:47:06.923Z] [NOTICE] - ============================================================
[2018-07-18T17:47:06.923Z] [NOTICE] -                        PROVISIONING
[2018-07-18T17:47:06.923Z] [NOTICE] - ============================================================
[2018-07-18T17:47:06.923Z] [NOTICE] - Spec.ID: 8a8f9ab216a980cc3867362a39ed4909
[2018-07-18T17:47:06.923Z] [NOTICE] - Spec.Name: dh-rdsmysql
[2018-07-18T17:47:06.923Z] [NOTICE] - Spec.Image: docker.io/awsservicebroker/rdsmysql-apb:latest
[2018-07-18T17:47:06.923Z] [NOTICE] - Spec.Description: AWS Service Broker - Amazon RDS for MySQL
[2018-07-18T17:47:06.923Z] [NOTICE] - ============================================================
[2018-07-18T17:47:06.923Z] [INFO] - Checking if namespace  exists.
[2018-07-18T17:47:06.923Z] [ERROR] - broker::Provision error occurred. Project  does not exist

What does the error "Project does not exist" mean?

My broker is deployed to a Kubernetes cluster and I've also registered this broker in Cloud Foundry. My assumption was that both Cloud Foundry and Kubernetes could share the same broker since they both depend on the same API. Let me know if this assumption is incorrect.

Do I need to create some resource in Kubernetes each time I create a service from the Cloud Foundry marketplace? I can see all of the services/plans in the marketplace but the provisioning seems to be failing with the error above.

Service Still Pending When Provisioning Fails

When the CloudFormation Stacks fails and is rolled back, the Provisioned Services are still Pending in the Console.

When deleted they are cleared up when the CloudFormation Stack has been destroyed, expected behaviour is that the same would happen at some point after failure

openshift v3.11.0+314d321-53
kubernetes v1.11.0+d4cacc0

Deprovision does not remove item from metadata table

If you deprovision a service instance and try to provision one later with the same ID, it'll fail because of the conflicting item in the metadata table.

Environment

• Application Platform: Kubernetes
• Application Platform Version: v1.10.7
• Broker Version: 1.0.0-beta.2

Allow overriding with an empty string

Right now, only non-empty overrides are accepted:

aws-servicebroker/pkg/broker/util.go

Lines 86 to 89 in c7bc93a

	if envvar[1] != "" {
	Overrides[key] = envvar[1]
	glog.V(10).Infof("%q=%q\n", key, envvar[1])
	}

However, there may be times when an empty override is desired. For example, I may want to override target_account_id to "" so that the parameter is removed from plans and resources are always provisioned in the current account.

Waiting for a ServiceInstance to be provisioned might waste too much time

Describe the bug
I noticed that when waiting for a ServiceInstance to be created (async operation), the broker starts with 2 seconds and then increase it exponentially (2, 4, 8, 16, 32 etc). So if you reach the step 512 seconds actually (a little more than 8 minutes) and your cloud formation stack is not ready yet, next you are going to wait for 1024 (more than 16 min).
Of course this is not critical, but it can delay a running pipeline pretty much, so it can be a nice improvement.

To Reproduce
I installed the AWS Service Broker and created a Postgres RDS Service Instance:

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: dev-rds-postgresql
spec:
  clusterServiceClassExternalName: rdspostgresql
  clusterServicePlanExternalName: custom
  parameters:
    AccessCidr: 172.20.0.0/16 # REQUIRED
    AllocatedStorageAndIops: 100 GB / 1,000 IOPS # OPTIONAL
    DBInstanceClass: db.t2.medium # OPTIONAL
    EngineVersion: 9.6.3 # OPTIONAL
    PostgresServerTimezone: UTC # OPTIONAL
    MasterUsername: user
    MasterUserPassword: d67sfjs2dknfahD

Then checking the broker logs I see:

I1005 11:06:25.725980       1 awsbroker.go:239] Client OSB API Version: "2.13"
I1005 11:06:25.726138       1 apisurface.go:89] Received ProvisionRequest for instanceID "b33e3355-c88e-11e8-bf6f-0a5864601c5d"
[...]
I1005 11:06:33.837661       1 awsbroker.go:239] Client OSB API Version: "2.13"
I1005 11:06:33.837690       1 apisurface.go:233] Received LastOperationRequest for instanceID "b33e3355-c88e-11e8-bf6f-0a5864601c5d"
[...]
I1005 11:07:30.072533       1 awsbroker.go:239] Client OSB API Version: "2.13"
I1005 11:07:30.072559       1 apisurface.go:233] Received LastOperationRequest for instanceID "b33e3355-c88e-11e8-bf6f-0a5864601c5d"
[...]
I1005 11:10:42.244319       1 awsbroker.go:239] Client OSB API Version: "2.13"
I1005 11:10:42.244349       1 apisurface.go:233] Received LastOperationRequest for instanceID "b33e3355-c88e-11e8-bf6f-0a5864601c5d"
[...]
I1005 11:14:58.355522       1 awsbroker.go:239] Client OSB API Version: "2.13"
I1005 11:14:58.355550       1 apisurface.go:233] Received LastOperationRequest for instanceID "b33e3355-c88e-11e8-bf6f-0a5864601c5d"
[...]
I1005 11:40:34.586522       1 awsbroker.go:239] Client OSB API Version: "2.13"
I1005 11:40:34.586653       1 apisurface.go:233] Received LastOperationRequest for instanceID "b33e3355-c88e-11e8-bf6f-0a5864601c5d"
[...]
I1005 11:40:34.690669       1 api.go:249] CREATE_COMPLETE

I missed some iterations, there were just too many to show. In this case there were around 12 minutes I just waited for the next iteration since the stack was complete.

Expected behavior
I think the step should have a max value, like 128 or 256 seconds and stop increasing it after that.
So after it reaches 2-4 minutes for updates, it could stick to that value.

I did try to find the code that handles that, but I don't see where the PollLastOperation from the service-broker-client library is being called.

Additional context
Kubernetes Kops Cluster on AWS
Kubernetes version: 1.10.5
Broker Version: 1.0.0-beta.2

Using a target role with a path other than "/" is undocumented/unintuitive

Describe the bug
When deploying the aws-servicebroker, it is necessary to specify a "target role".
If the target (IAM) role has been created with a path other than "/", the leading slash of the role's path causes trouble and leads to a double-slash when the servicebroker tries to assume the role

To Reproduce

• Create an IAM role with a path other than "/", ARN shjould be something like e.g. arn:aws:iam::123456789012:role/foo/bar/aws-service-broker
• Deploy the aws-service broker (preferably with it's helm chart) and set the parameter aws.targetrolename to /foo/bar/aws-service-broker

Expected behavior
The role that the service broker tries to assume should be arn:aws:iam::123456789012:role/foo/bar/aws-service-broker, but instead arn:aws:iam::123456789012:role//foo/bar/aws-service-broker (notice the double-slash!) will be assumed... which fails.

Workaround
Took me some time to figure out, that just dropping the leading slash works as expected, even though it's not really intuitive.

Environment (please complete the following information):

• Application Platform: EKS
• Application Platform Version: 1.10.3
• Broker Version: 1.0.0-beta.2

svcat get classes does not have any results

Describe the bug
svcat get classes
NAME NAMESPACE DESCRIPTION
+------+-----------+-------------+

To Reproduce
Installed using helm alpha v3 chart with tols fix from v4

Expected behavior
Classes like s3, rds, etc shoudl have been displayed

Environment (please complete the following information):

• Application Platform: EKS
• Application Platform Version: latestversion platform v2
• Broker Version 0.1.38

Additional context
kubectl logs aws-servicebroker-59cb7cf9b9-bzvmg --namespace aws-servicebroker
I1204 15:50:45.326956 1 util.go:194] Did not find 'aws_access_key' and 'aws_secret_key' in params, using default chain.
I1204 15:50:45.327004 1 aws_sdk.go:71] Parameter 'target_role_name' not set. Not assuming role.
I1204 15:50:45.327022 1 util.go:194] Did not find 'aws_access_key' and 'aws_secret_key' in params, using default chain.
I1204 15:50:45.327038 1 aws_sdk.go:71] Parameter 'target_role_name' not set. Not assuming role.
I1204 15:50:45.394513 1 awsbroker.go:36] Running as caller identity '{
Account: "xxxxxxxxxxxxxx",
Arn: "xxxxxxxx",
UserId: "AROAJURTH4BW4VG4PTZLQ:i-0f544e0915d1c52bf"
}'.
I1204 15:50:45.394558 1 util.go:90] "awsservicebroker_all_all_all_VpcId"="vpc-xxxxxx"
I1204 15:50:45.394567 1 util.go:90] "awsservicebroker_all_all_all_target_account_id"="xxxxx"
I1204 15:50:45.394571 1 util.go:90] "awsservicebroker_all_all_all_target_role_name"="xxxxxxxZ"
I1204 15:50:45.394579 1 util.go:90] "awsservicebroker_all_all_all_region"="us-east-1"
I1204 15:50:45.394594 1 awsbroker.go:174] Listing objects bucket: awsservicebroker2 region: us-east-1 prefix: templates/latest
I1204 15:50:45.490059 1 awsbroker.go:193] Found 0 objects
I1204 15:50:45.490072 1 awsbroker.go:168] Updating listings cache with []
I1204 15:50:45.490394 1 main.go:115] Starting broker!
I1204 15:50:45.490401 1 main.go:128] Starting secure broker with file based TLS cert and key
I1204 15:50:45.490405 1 server.go:138] Starting server on :3199
I1204 15:51:45.068819 1 awsbroker.go:208] Client OSB API Version: "2.13"
I1204 15:51:45.068842 1 api.go:25] []
I1204 15:51:45.143777 1 awsbroker.go:208] Client OSB API Version: "2.13"
I1204 15:51:45.143793 1 api.go:25] []
I1204 15:51:45.344104 1 awsbroker.go:208] Client OSB API Version: "2.13"
I1204 15:51:45.344128 1 api.go:25] []

svcat sync broker aws-servicebroker
Error: could not sync service broker aws-servicebroker (unable to get broker 'aws-servicebroker' (servicebrokers.servicecatalog.k8s.io "aws-servicebroker" not found))

svcat get brokers
NAME NAMESPACE URL STATUS
+-------------------+-----------+---------------------------------------------------------------+--------+
aws-servicebroker https://aws-servicebroker.aws-servicebroker.svc.cluster.local Ready

No example for custom resources

Describe the bug

In the Documentation README it says there is an example custom spec file at:

/examples/example-spec.yaml

There is not.

To Reproduce

Go to https://github.com/awslabs/aws-servicebroker/tree/master/docs and scroll to the end

Expected behavior

Clicking the Example -spec.yaml file link does not 404

Screenshots
N/A

Environment (please complete the following information):
N/A

Additional context
Add any other context about the problem here.

Documentation points to broken link to Docker Hub

Documentation awslabs/aws-servicebroker/edit/master/docs/getting-started-openshift.md points to https://hub.docker.com/u/awsservicebroker/dashboard instead of https://hub.docker.com/u/awsservicebroker/.

TLS in transit for RDS

RDS templates should offer TLS in transit and enforce it's use in production service plans. any needed certificates should also be returned as part of the binding process. Thought should also go into how to handle certificate rotation.

RDS - k8s Missing arguments

Seems like the broker is not passing some defaults to the provisioner and for this reason fails to create the new stack.

• aws_cloudformation_role_arn
• region
• VpcId
• SBArtifactS3Bucket

Is this the intended behavior ?

I've managed to work with the following config.

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: rds
spec:
  clusterServiceClassExternalName: dh-rdsmysql
  clusterServicePlanExternalName: dev
  parameters:
      aws_access_key: "use-role"
      aws_secret_key: "use-role"
      aws_cloudformation_role_arn: "arn:aws:iam::99999999999:role/aws-servicebroker-cfn-deploy-role"
      region: "us-east-1"
      VpcId: "vpc-a0a0a0a0"
      SBArtifactS3Bucket: "awsservicebroker"
      AccessCidr: "172.20.0.0/16"