awslabs / aws-servicebroker Goto Github PK
View Code? Open in Web Editor NEWAWS Service Broker
License: Apache License 2.0
AWS Service Broker
License: Apache License 2.0
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
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.
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):
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):
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
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.
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
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):
Additional context
AwsBroker.Provision
rejects requests with unknown parameters; it does not check nonCfnParams
(where the role stuff is).
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.
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/.
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
Hi, I have a couple of questions around deploying and then using AWS Service Broker
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?
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
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.
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):
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='
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):
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.
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
arn:aws:iam::123456789012:role/foo/bar/aws-service-broker
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):
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):
Additional context
It's a fresh installation and provisioning never worked.
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.
This would improve overall user experience, reducing complexity of deployments and fostering reusability across brokered services.
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?
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!
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!
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
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
Seems like the broker is not passing some defaults to the provisioner and for this reason fails to create the new stack.
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"
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 ?
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):
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
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
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.
Describe the bug
I'm unable to install aws-servicebroker with the provided helm documentation
To Reproduce
Assuming helm and tiller is already installed:
helm repo add aws-sb https://awsservicebroker.s3.amazonaws.com/charts
helm install aws-sb/aws-servicebroker --name aws-servicebroker --namespace aws-sb --version 1.0.0-beta.2
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):
$ 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"}
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?
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.
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):
enable selceting a storage class for buckets
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
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!
Describe the bug
the installation with helm charts as described here fails when installing the broker
To Reproduce
Prereq: helm works
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm repo update
helm install svc-cat/catalog --name catalog --namespace catalog
helm repo add aws-sb https://awsservicebroker.s3.amazonaws.com/charts
helm repo update
helm inspect aws-sb/aws-servicebroker
fails with: Error: failed to download "aws-sb/aws-servicebroker" (hint: running
helm repo update may help)
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):
$ 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"}
Additional context
kubernetes deployed to aws with kops.
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.
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?
Add a parameter to allow restoring from snapshot on provision.
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?
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).
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
Right now, only non-empty overrides are accepted:
aws-servicebroker/pkg/broker/util.go
Lines 86 to 89 in c7bc93a
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.
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).
Customising a few databases parameters through parameter group.
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>
Change parameter group after create RDS.
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
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):
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
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.
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
cf create-service rdsmysql dev my-db -c '{"AccessCidr":"[REDACTED]", "VpcId":"[REDACTED]", "MasterUsername":"[REDACTED]"}'
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):
Support for AWS Elasticsearch Service would help with bootstrapping logging infrastructure in new clusters.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.