I'm trying to setup AWS CLI login via OneLogin - but it doesn't seem to work.
I created the onelogin.sdk.properties file as follows:
onelogin.sdk.client_id=xxxxxxxxxxxxxxxxxxxxxxxxxxx
onelogin.sdk.client_secret=xxxxxxxxxxxxxxxxxxxxxxxxxxx
onelogin.sdk.region=us
onelogin.sdk.ip=
I'm running the below command from the same directory where the above properties file resides:
java -jar onelogin-aws-cli.jar --appid 123456 --subdomain mycompany --username myusername --region us-east-1 --profile onelogin
This prompts me for the password and after I enter it, I get the following error:
Exception in thread "main" OAuthProblemException{error='bad request', description='bad request', uri='null', state='400', scope='null', redirectUri='null', responseStatus=400, parameters={}}
at org.apache.oltu.oauth2.common.exception.OAuthProblemException.error(OAuthProblemException.java:59)
at org.apache.oltu.oauth2.client.validator.OAuthClientValidator.validateErrorResponse(OAuthClientValidator.java:63)
at org.apache.oltu.oauth2.client.validator.OAuthClientValidator.validate(OAuthClientValidator.java:48)
at org.apache.oltu.oauth2.client.response.OAuthClientResponse.validate(OAuthClientResponse.java:127)
at com.onelogin.sdk.conn.OneloginOAuthJSONResourceResponse.init(OneloginOAuthJSONResourceResponse.java:31)
at org.apache.oltu.oauth2.client.response.OAuthClientResponse.init(OAuthClientResponse.java:101)
at org.apache.oltu.oauth2.client.response.OAuthClientResponse.init(OAuthClientResponse.java:120)
at org.apache.oltu.oauth2.client.response.OAuthClientResponseFactory.createCustomResponse(OAuthClientResponseFactory.java:82)
at com.onelogin.sdk.conn.OneloginURLConnectionClient.execute(OneloginURLConnectionClient.java:75)
at org.apache.oltu.oauth2.client.OAuthClient.resource(OAuthClient.java:81)
at com.onelogin.sdk.conn.Client.getSAMLAssertion(Client.java:2238)
at com.onelogin.aws.assume.role.cli.OneloginAWSCLI.getSamlResponse(OneloginAWSCLI.java:437)
at com.onelogin.aws.assume.role.cli.OneloginAWSCLI.main(OneloginAWSCLI.java:256)
I know for a fact that my onelogin.sdk.properties is correct, because intentionally setting incorrect client_id/client_secret or changing the region to eu makes the application fail with another error (error='Unauthorized')
What might be the problem?
Is there a debug switch I can use to help me understand what's going on?
Thanks,
Yosi
The problem was me using the username in incorrect format (needed the domain suffix - e.g. myusername#mydomain.com)
Related
I have created a script in linux with content-
sqlplus -silent test/test123#XYZ <<SQL_QUERY
select * from test.persons;
SQL_QUERY
Here-
test - username
test#123 - password
XYZ - SID Name
But wen I am running this I am getting error -
ERROR:
ORA-12154: TNS:could not resolve the connect identifier specified
ERROR:
ORA-12162: TNS:net service name is incorrectly specified
SP2-0306: Invalid option.
Can anyone please help me with this issue ?
Thanks in advance!
Based on this:
test - username
test#123 - password
XYZ - SID Name
I am guessing that you actually tried to run:
sqlplus -silent test/test#123#XYZ
which is why SQL*Plus would have complained because of the 2 "#".
Try putting your password in double quotes to avoid this. An even better way is to put the password in a connection wallet, so its never coded in the script. See this post for how to do this
https://connor-mcdonald.com/2015/09/21/connection-shortcuts-with-a-wallet/
I was trying to showcase binary authorization to my client as POC. During the deployment, it is failing with the following error message:
pods "hello-app-6589454ddd-wlkbg" is forbidden: image policy webhook backend denied one or more images: Denied by cluster admission rule for us-central1.staging-cluster. Denied by Attestor. Image gcr.io//hello-app:e1479a4 denied by projects//attestors/vulnz-attestor: Attestor cannot attest to an image deployed by tag
I have adhered all steps mentioned in the site.
I have verified the image repeatedly for few occurances, for example using below command to force fully make the attestation:
gcloud alpha container binauthz attestations sign-and-create --project "projectxyz" --artifact-url "gcr.io/projectxyz/hello-app#sha256:82f1887cf5e1ff80ee67f4a820703130b7d533f43fe4b7a2b6b32ec430ddd699" --attestor "vulnz-attestor" --attestor-project "projectxyz" --keyversion "1" --keyversion-key "vulnz-signer" --keyversion-location "us-central1" --keyversion-keyring "binauthz" --keyversion-project "projectxyz"
It throws error as:
ERROR: (gcloud.alpha.container.binauthz.attestations.sign-and-create) Resource in project [project xyz] is the subject of a conflict: occurrence ID "c5f03cc3-3829-44cc-ae38-2b2b3967ba61" already exists in project "projectxyz"
So when I verify, I found the attestion present:
gcloud beta container binauthz attestations list --artifact-url "gcr.io/projectxyz/hello-app#sha256:82f1887cf5e1ff80ee67f4a820703130b7d533f43fe4b7a2b6b32ec430ddd699" --attestor "vulnz-attestor" --attestor-project "projectxyz" --format json | jq '.[0].kind' \
> | grep 'ATTESTATION'
"ATTESTATION"
Here are the screen shots:
Any feedback please?
Thanks in advance.
Thank you for trying Binary Authorization. I just updated the Binary Authorization Solution, which you might find helpful.
A few things I noticed along the way:
... denied by projects//attestors/vulnz-attestor:
There should be a project ID in between projects and attestors, like:
projects/my-project/attestors/vulnz-attestor
Similarly, your gcr.io links should include that same project ID, for example:
gcr.io//hello-app:e1479a4
should be
gcr.io/my-project/hello-app:e1479a4
If you followed a tutorial, it likely asked you to set a variable like $PROJECT_ID, but you may have accidentally unset it or ran the command in a different terminal session.
After pointed to another repository problem solved, but before that you were having problems and there could be many reasons. please contact support with error message if you are having the same problem.
Using amplify init, right after choosing which profile to use, I get this error and am not sure why:
✖ Root stack creation failed
init failed
TypeError: Cannot redefine property: default
I tried changing the different user to be my default in my credentials file and then picking the default profile in the amplify init step for that - same error.
I tried saying I didn't want to use a profile and instead putting in my access key id and secret key in manually, also didn't work.
Found solution here! github issues
Relevant quote - "I found the source of my problem... My ~/.aws/config file contained entries called [default] and [profile default], which causes the symptom."
So I removed the [default] and just left my [profile default] and then the amplify init went through normally!
Amplify expects you to have had an existing user with AdministrationFullAccess. This should be confirmed before running amplify init or perhaps when you run the amplify init you will be prompted if you would be using the default AWS Profile or not. In this case, you might have to create the user yourself and attach a policy to the user and paste both the access and secret keys to the respective section on the console. But when you follow the steps to create a user with amplify configure it is so easy.
On SonarCloud, I created an organization and a user (from GitHub), plus a project. For the user I created a token. Then I ran the command
mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.5.0.1254:sonar -Dsonar.projectKey=<project key> -Dsonar.organization=<my org> -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=<token>
I come up with the error message
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.5.0.1254:sonar (default-cli) on project XXX: You're not authorized to run analysis. Please contact the project administrator.
In the project settings > Administration > Permissions, the user does have "Execute Analysis" permission.
If I add the "Execute Analysis" permission to Anyone, the command above works (it does not need the -Dsonar.login option).
Does anyone have a clue?
Adding the "Execute Analysis" permission to the SonarCloud user who generated the token should be enough.
Can you retry with:
mvn sonar:sonar
"-Dsonar.projectKey=<project key>" \
"-Dsonar.organization=<my org>" \
"-Dsonar.host.url=https://sonarcloud.io" \
"-Dsonar.login=<token>"
In case it doesn't work, can you provide the output of the command?
It turns out that SonarCloud works as expected. I had forgotten that some people in my organization seem to enjoy making their colleagues' life miserable. Sneakily removing items such as sonar.login from the requests is one among their tricks.
I have a node js application for a slack-bot deployed on StdLib for a slack-bot application that I created using the following tutorial: Build a serverless slack bot in 9 minutes with node js and stdlib
Now, everything is up and running, but I just want to see the logs of my application from StdLib.
I am already logged in as the authenticated user from my terminal and I am able to execute the command lib up dev successfully.
But, now when I try to view the logs using the command: lib logs dev, i get the following error:
Error: You must be signed in as a service's owner or be part of the service's team to to view logs for a service
Can anyone help me understand what i am doing wrong and how to access the dev logs from StdLib?
EDIT: I also tried logging in again by using lib login --email <my email> and then again tried lib logs dev, but it resulted in the same error as above.
Interestingly, even after logging in, if I do lib info dev, It gives me the error Error: Bad Request: "<my username>" does not have permission to access "dev"
So, in case someone else is stuck with the same...
I was able to figure this out by checking out the following documentation:
https://docs.stdlib.com/main/#/creating-services/logging
basically I need to give the username and the app name in a specific fashion as follows:
lib logs <my username>.<my app>[#dev]
The error mentioned was kind of confusing and I could not decipher what I was doing wrong based on the error.