I setup a hyperledger composer in my aws ubuntu instance. I was able to connect to the blockchain through the playground UI as "hlfv1" connection, using the command:
composer-playground
I created a business network using the ID and enrollment secret as "admin" and "adminpw" and wrote the modelling file, script file and acl file and tested the network. Created multiple participants and issued identities to them and imported their cards to my wallet. It was working perfectly fine. But When after some time I'm trying to connect by clicking "Connect" on any of the cards in my wallet it throws the following error:
Error: Error trying login and get user Context. Error: Error trying to enroll user. Error: Enrollment failed with errors [[{"code":20,"message":"Authorization failure"}]]
And it doesn't get connected to the business network. I have used to correct ID and secret while creating. Any solution is highly appreciated.
Try to restart the network, delete and reimport all card.
Related
I'm quite new to github actions and gcloud. I have trouble to get my github-CI/CD-Pipeline running because I can't push any docker image to the google Cloud Registry due to access restrictions.
What have I done so far:
I have a Quarkus app hosted on github
I used github actions to build the Maven project and the docker image
I created a project in google Cloud and added a service account which I use for the github action. The login seems to work:
Run google-github-actions/setup-gcloud#master
/usr/bin/tar xz --warning=no-unknown-keyword -C /home/runner/work/_temp/ac85f67a-89fa-4eb4-8d30-3f6379124ec2 -f /home/runner/work/_temp/de491940-a4b1-4a15-bf0a-95d563e68362
/opt/hostedtoolcache/gcloud/342.0.0/x64/bin/gcloud --quiet config set project ***
Updated property [core/project].
Successfully set default project
/opt/hostedtoolcache/gcloud/342.0.0/x64/bin/gcloud --quiet auth activate-service-account github-actions#***.iam.gserviceaccount.com --key-file -
Activated service account credentials for: [github-actions#***.iam.gserviceaccount.com]
If I now try to push the docker image I get the following (expected) error message:
Run docker push "$GCR_HOSTNAME/$PROJECT_ID/$IMAGE:$IMAGE_TAG"
The push refers to repository [eu.gcr.io/***/***]
715ac1ae8693: Preparing
435cfe5f5775: Preparing
313d03d71d4d: Preparing
c5c8d86ccee1: Preparing
1b0f2238925b: Preparing
144a43b910e8: Preparing
4a2bc86056a8: Preparing
144a43b910e8: Waiting
4a2bc86056a8: Waiting
denied: Token exchange failed for project '***'. Caller does not have permission 'storage.buckets.get'. To configure permissions, follow instructions at: https://cloud.google.com/container-registry/docs/access-control
Error: Process completed with exit code 1.
Next, I opened the Google Cloud Console and created a custom role (IAM & Admin -> Roles -> Create Role) which has the necessary permissions.
Then, I had trouble to assign my new custom role to the service account (IAM & Admin -> Service Accounts -> Manage Access -> Add member). I used the email address of the service account as "New members", but I could not choose the custom role I just created. What am I missing here?
I read somewhere that I can also add service accounts as member (IAM & Admin -> IAM -> Add). Again I used the email address of the service account as "New Members". This time I could choose my custom role. What's the difference to the first approach?
Anyways, if a I try to run the github action again, now I get the following error:
Run docker push "$GCR_HOSTNAME/$PROJECT_ID/$IMAGE:$IMAGE_TAG"
The push refers to repository [eu.gcr.io/***/***]
c4f14c9d3b6e: Preparing
fe78d438e8e2: Preparing
843fcae4a8f4: Preparing
dcf8cc80cedb: Preparing
45e8815b101d: Preparing
144a43b910e8: Preparing
4a2bc86056a8: Preparing
144a43b910e8: Waiting
4a2bc86056a8: Waiting
denied: Access denied.
Error: Process completed with exit code 1.
The error message is different, so I guess the permission for the service account somehow worked, but still I can't succeed. Which steps did I miss?
Any help is highly appreciated. Thanks a lot!
One way to debug this is to create a key for the service account on your local host, configure your script|gcloud to use the service account as its credentials and then try the push manually.
One immediate problem may be that you're not authenticating against Google Container Registry (GCR). GCR implements Docker's registry API and you'll need to use one of the mechanisms to authenticate before you can interact with the registry.
Notes:
I think you don't need to create a custom role. You have 2 options. Either (preferred) create an account specifically for the CI/CD job and grant it the minimum set of roles needed including storage.buckets.get. I think you can start with roles/storage.admin (link) and perhaps refine later.
You can grant roles e.g. roles/storage.admin to a Project in which case the permission applies to all Cloud Storage resources or to a specific Bucket in which case the permission applies only to the bucket and its objects.
Service Accounts have a dual role in GCP. As an identity and as a resource (that can be used by other identities). It can be confusing.
When trying to deploy my container (or the hello world container) to google cloud run I receive this error:
ERROR: (gcloud.run.deploy) Cloud Run error: Internal system error. Missing necessary permission for service-<ID>#serverless-robot-prod.iam.gserviceaccount.com on resource <PROJECT ID>
I can see that the service account mentioned in the error is in my IAM dashboard and has the Google Cloud Run Service Agent role. I even tried giving it the Owner role, but it didn't work.
I tried including the --service-account flag with the same service account and receive this error:
PERMISSION_DENIED: Permission 'iam.serviceaccounts.actAs' denied on service account service-<ID>#serverless-robot-prod.iam.gserviceaccount.com (or it may not exist).
Which I know doesn't make sense.
I also tried this deploy through the console ui, but received the same error (the first one).
How do I fix this permission error?
I order to assign the iam.serviceAccounts.actAs permission you have to set the roles/iam.serviceAccountUser role.
You can do this by going to the Console > IAM & Admin and setting the Service Account User role to your service account.
Also, confirm that the Cloud Run runtime service account also has the iam.serviceAccounts.actAs permission. This is a requirement specified in the Cloud Run deployment permissions docs
As Dustin mentioned, there was an outage affecting IAM permissions. Now that the outage has been resolved, my deployment is working!
I am using Docker Swarm and docker-compose to setup my Fabric (v1.1) and Composer (v0.19.18) networks.
I wanted to test how my Swarm/Fabric networks would respond to a host/ec2 failure, so I manually reboot the host which is running the fabric-ca, orderer, and peer0 containers.
Before the reboot, everything runs perfectly with respect to issuing identities. After the reboot, though all of the Fabric containers are restarted and appear to be functioning properly, I am unable to issue identities with the main admin#network card.
After reboot, composer network ping -c admin#network returns successfully, but composer identity issue (via CLI or javascript) both return code 20 errors as described here:
"fabric-ca request register failed with errors [[{\"code\":20,\"message\":\"Authorization failure\"}]]"
I am guessing the issue is stemming from the host reboot and some difference in how it is restarting the Fabric containers. I can post my docker-compose files if necessary.
If your fabric-ca-server has restarted and it's registration database hasn't been persisted (for example the database is stored on the file system of the container and loss of that container means loss of the contents of that file system) then the ca-server will create a completely new bootstrap identity called admin for issuing identities and it won't be the one you have already have and therefore isn't a valid identity anymore for the fabric-ca-server. Note that it will be a valid identity for the fabric network still. So this is why you now get authorisation failure from the fabric-ca-server. The identity called admin that you currently have is not known to your fabric-ca-server anymore.
I'm running tests and pushing my docker images from CircleCi to Google Container Registry. At least I'm trying to.
Which roles does my service account require to be able to pull and push images to GCR?
Even as an account with the role "Project Owner", I get this error:
gcloud --quiet container clusters get-credentials $PROJECT_ID
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials)
ResponseError: code=403,
message=Required "container.clusters.get" permission(s)
for "projects/$PROJECT_ID/locations/europe-west1/clusters/$CLUSTER".
According to this doc, you will need the storage.admin role to Push (Read & Write), and storage.objectViewer to Pull (Read Only) from Google Container Registry.
On the topic of not being able to get credentials as owner, you are likely using the service account of the machine instead of your owner account. Check which account you are using with the command:
gcloud auth list
You can change the service account the machine is using through the UI by first stopping the instance, then editing the service account. You can also use your Google credentials using the command:
gcloud auth login
Hope this helps
When you get Required "___ANYTHING____" permission message:
go to Console -> IAM -> Roles -> Create new custom role [ROLE_NAME]
add container.clusters.get and/or whatever other permissions you need in order to get the whole thing going (I needed some rights for kubectl for example)
assign that role (Console -> IAM -> Add+) to your service account
I have been following the tutorials which are provided in Hyperledger Composer docs, but I am not getting the results that they are supposed to I should be getting. Specifically, when I try to enable the multiple user mode for the REST server and I try to call one of the business network REST API operations using the REST API explorer I always get a HTTP 401 Authorization Required. According to the Tutorial, I if get this error is due to I have not authenticated correctly to the REST API, but it does not mention why this error occurs or how I may fix it.
It is very important for application development to be able to authenticate each user who wants to make requests to the API.
What version of Hyperledger Composer are you using?
The tutorial/document you refer to is correct for v0.15.0 and works a little differently for prior versions.
Are you seeing an Access token at the top of the Browser Window - this indicates that you have successfully authenticated and can continue with the steps for the Wallet.
If you are not seeing an Access token displayed, then make sure you hit your REST server with a URL similar to http://localhost:3000/auth/github again and login.
If you are still experiencing problems I would suggest going back to just using authentication without multiuser mode and verify that the authentication works properly from there.
After some research, I found a solution and worked for me.
If you already enable Github authentication then ignore. Otherwise first enable authentication following this tutorial Enaling Authentication.
Before start rest server you will export your admin card from the network by using this command:
composer card export -n admin#sample-network -f admincard.card
Now start rest server with authentication using this command:
composer-rest-server -c admin#sample-network -p 3000 -a true -m true
After some time rest server will start.
Now First, go this link for authentication: http://localhost:3000/auth/github
After successful authentication, you will get an access token and also you will see a Wallet options below.
Now you need to import a card that you already export from your network.
That's it, you can able to add anything to your network.
In my case, I have two missed steps:
enabling authentication for the REST server
https://hyperledger.github.io/composer/v0.19/integrating/enabling-rest-authentication.html
composer-rest-server -c admin#you_project -a true, I just execute composer-rest-server but did not specify the identity "admin#you_project" before.