I have a shell script trying to download some secrets from secret manager inside dataproc cluster.
GetAuthJson() {
authjson=$(curl "https://secretmanager.googleapis.com/v1/projects/$PROJECT_ID/secrets/$AUTH_JSON/versions/1:access" \
--request "GET" \
--header "authorization: Bearer $(gcloud auth print-access-token)" \
--header "content-type: application/json")
if [ $? -ne 0 ]; then
Error "Unable to extract the $PIPENAME Auth json details from GCP Secret Manager"
fi
echo $authjson | grep -o '"data": "[^"]*' | grep -o '[^"]*$' >$BASE_DIR/encodedauth.json
if [ $? -ne 0 ]; then
Error "Unable to save the $PIPENAME auth.json server secret to auth.json"
fi
auth_json=$(base64 -d $BASE_DIR/encodedauth.json)
base64 -d $BASE_DIR/encodedauth.json >/etc/secrets/auth.json
if [ $? -ne 0 ]; then
Error "Unable to decode the $PIPENAME auth.json server secret"
fi
Log "auth.json secret extraction done"
}
when i run this curl it generates an error
authjson='{
"error": {
"code": 403,
"message": "Permission '\''secretmanager.versions.access'\'' denied for resource '\''projects/**-**-dev/secrets/**_AUTH_JSON/versions/1'\'' (or it may not exist).",
"status": "PERMISSION_DENIED"
}
}'
the same curl with same service account is working in local meachine. and more over if i copy the CURL from local and run it in dataproc cluster it works as well.
But the curl generated from dataproc fails in local .
whats more weird is if i run gcloud auth print-access-token separately and paste it in curl command it works in both meachine.
so my question is why gcloud auth print-access-token generated as part of curl in dataproc cluster is not working ?
It would be useful if you could capture the value of the curl command or, at least the value of gcloud auth print-access-token that's failing in the script.
I suspect (I'm unfamiliar with Dataproc) that the Dataproc instance does not have gcloud installed and the gcloud auth print-access-token is failing.
If the instance does have gcloud installed, since it's running then it must have a Service Account and so should permit authenticating. There may (!?) be a more nuanced issue with getting an access token as a Dataproc instance, unclear.
Please consider using either gcloud secrets versions access directly or one of Google's client libraries to access the secret.
You're making the process more complex than it need be by curl'ing the endpoint; you're having to use gcloud anyway to get the auth token.
The issue was i ran the script as sudo user. When i ran normally it worked.
Related
I'm trying to pass my environment secret to gcloud auth for a service account. I currently am doing it by creating a json file that gcloud can load.
printf "%s" "$GCP_KEY" >> GCP_KEY.json
gcloud auth activate-service-account --key-file=GCP_KEY.json
I would like to avoid creating a file with this secret.
Ideally, I would like something similar to:
printf "%s" "$GCP_KEY" | gcloud auth activate-service-account --key-file=/dev/stdin
Unfortunately, gcloud uses the filename to determine whether the key is in json format or p12. Is there any way to make gcloud see it as a file with a filename ending in .json?
I took a look at the gcloud auth activate-service-account command here and it says the --key-file param is required so how about deleting the file once the command ran successfully, you can do this as follow:
gcloud auth activate-service-account --key-file=GCP_KEY.json ; rm GCP_KEY.json
I am trying to connect kibana to an elasticsearch server, where the username is "elastic", which means I cannot use the user and password to connect to the server, I have to use a token.
I tried to run command curl -H "Authorization: Bearer dGhpcyBpcyBub3Qx5...F0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==" http://localhost:9200
However, this doesn't work, the error message says I did not provide enough credentials, which makes sense since this server is password protected.
And then I tried to run the command curl -H "Authorization: Bearer dGhpcyBpcyBub3Qx5...F0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ==" http://localhost:9200 -u elastic:password, but it still doesn't work and tells me the command syntax is wrong.
What should I do?
The below script is to trigger pipeline in Azure devops via REST, Its working fine on an existing pipeline, but when trying on newly created pipeline which has never ran then its throwing below error. Any help or suggestion would be really appreciated.
{"$id":"1","innerException":null,"message":"No pool was specified.\nUnexpected parameter 'pool'","typeName":"Microsoft.Azure.Pipelines.WebApi.PipelineValidationException, Microsoft.Azure.Pipelines.WebApi","typeKey":"PipelineValidationException","errorCode":0,"eventId":3000}
#!/bin/bash
echo "Enter PAT Token"
read -r PAT
echo "Enter Organization name"
read -r OrganizationName
echo "Enter Project ID"
read -r projectId
pipelineId=$(jq -r '.id' PipeOutput.txt) #Get definition ID from external TXT file
"Trigger_Pipeline=$(curl --write-out "%{http_code}\n" -X POST -L \
-u :"$PAT" "https://dev.azure.com/""${OrganizationName}""/""${projectId}""/_apis/pipelines/""${pipelineId}""/runs?api-version=6.0-preview.1" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{
"resources": {
"repositories": {
"self": {
"refName": "refs/heads/master"
}
}
}
}' --output Triggeroutput.txt --silent)"
echo "Output: $(Trigger_Pipeline)"
I tested this REST API with the newly created classic pipeline and YAML pipeline, it works fine on both pipelines.
For us to investigate this issue further, please share the YAML file of the newly created pipeline definition.
In addition, please also try with the following steps:
Try execute the REST API with another method to see if it work, such as on Postman client.
Try to manually trigger this new pipeline to see if it can work.
If the manual trigger works, try using the REST API trigger again.
I am trying to authenticate my OpenVPN clients (with a username and password) using a bash script. Here is part of my server side config:
client-to-client
username-as-common-name
client-cert-not-required
script-security 3
auth-user-pass-verify '/etc/openvpn/script/auth.sh' via-env
Here is my bash script:
#!/bin/bash
SECRET='mysecret'
RESPONSE=$(sudo /usr/bin/curl https://myvpn.com/somedir/auth.php -d"username=$1&password=$2&secret=$SECRET" --silent)
if [ "$RESPONSE" = "y" ]; then
exit 0
else
exit 1
fi
When I run it on the command line (./auth.sh) it runs fine and authenticates correctly. I have setup my php script on my webserver such that it generates a log everytime it is called, so I know if the request successfully reached. However, when OpenVPN calls the script, the curl request fails to send (authentication fails on client side). My guess is that for some reason OpenVPN doesn't have permission to use cURL? How do I give OpenVPN permission to use curl?
Note: I have tried putting exit 0 on top of my bash script, and it successfully authenticates the user and connects to the VPN.
If you don't need sudo, you can do it with:
#!/usr/bin/env bash
SECRET='mysecret'
[ 'Y' = "$(
/usr/bin/curl \
--data "username=$1&password=$2&secret=$SECRET" \
--silent \
'https://myvpn.com/somedir/auth.php'
)" ]
No need to exit with explicit return code, since the test will take care of it?
https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0/apis/auth_manage_api.html
I try to use the API for common user integrated with OIDC, but the error msg shows:
{"error_description":"invalid_resource_owner_credential","error":"server_error"}
command as the following
curl -k -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -d "grant_type=password&username=abc\#test\.com&password=ChangeMe\!\#\#&scope=openid" https://<cluster_access_ip>:8443/idprovider/v1/auth/identitytoken --insecure
But it is working fine for the administrator: admin/admin, so strange.
Issue is with the special character "!" which is used for history expansions in command line prompt.
You can use below command which works...
curl -k -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -d "grant_type=password&username=abc#test.com&password=ChangeMe"'!'"##&scope=openid" https://<cluster_access_ip>:8443/idprovider/v1/auth/identitytoken --insecure
Have you configured the LDAP, created Teams and added users to the team? Did you check the logs on Master node /var/log/containers for platform-identity-manager, _platform-auth-service, *platform-identity-provider?