We would like to create service user to manage ci/cd workflow for the different teams. Secret tokens can be generated for the service account to perform API operations.
oc create sa sample
oc policy add-role-to-user developer system:serviceaccount:sampleproject:sample
oc describe sa sample
oc describe sa secret sample-token-5s5kl
Above describe command gives us the secret token which we hand over to different teams for their API operations. But the problem we are facing currently is, secret token expires in 4 hrs or so. Is there a way to create never expiring secret tokens ?
If I am not wrong, they don't expire. Also, I quote from Openshift documentation "The generated API token and registry credentials do not expire, but they can be revoked by deleting the secret. When the secret is deleted, a new one is automatically generated to take its place."Please refer to this page for more info
Related
Is there an API in Ping Federate/ Ping One to validate user credentials - username and password?
Here is a scenario in which I would like to use it:
user logs in via SAML SSO to my web application
certain application feature requires that the user credentials are validated again (to sign-off some operation)
SAML SSO does not make it easy to re-validate user credentials without logging out from application, users passwords are obviously not stored in the application so the only way to validate credentials is to send them via some API to Ping to validate - however I was unable to find such API in Ping.
For example, OKTA (which offers similar services as Ping) does provide such API:
curl -v -X POST \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{
"username": "dade.murphy#example.com",
"password": "correcthorsebatterystaple"
}' "https://${yourOktaDomain}/api/v1/authn"
I am looking for something similar in Ping.
Yes - there are two options in PingFederate for this:
Authentication API - This enables clients to authenticate users via a REST API instead of having the adapters present login templates directly. More details here: https://docs.pingidentity.com/bundle/pingfederate-102/page/elz1592262150859.html
OAuth Resource owner password credentials grant type - If you're just looking to validate a username + password combination you could leverage PingFederate's support of OAuth ROPC grant type. It allows you to POST the credentials and get back an Access Token if it was successful. More details here: https://docs.pingidentity.com/bundle/pingfederate-102/page/lzn1564003025072.html
Karolbe, you may also wish to take a look at Adaptive Authentication feature provided by PingFederate which directly answers your second requirement as provided by you above, i.e. - certain application feature requires that the user credentials are validated again (to sign-off some operation). Here is the reference from PingIdentity website. Adaptive authentication and authorization allow you to evaluate contextual, behavioral and correlated data to make a more informed decision and gain a higher level of assurance about a user’s identity, which is what your requirement 2) is asking for. Typical use case could be, say a user tries to access a high valued application, or tries to login after a configured idle time, Adaptive authentication will force user to present authentication credentials again.
For our product we have decided to implement a Secret Management tool (AWS secrets manager) that will securely store and manage all our secrets such as DB credentials, passwords and API keys etc.
In this way the secrets are not stored in code, database or anywhere in the application. We have to provide the AWS credentials - Access Key Id and Secret access key to programmatically access the APIs of Secrets manager.
Now the biggest question that arises is, where to keep this Initial Trust – the credentials to authenticate the AWS secrets manager.? This is a bootstrapping problem. Again, we have to maintain something outside of the secret store, in a configuration file or somewhere. I feel If this is compromised then there is no real meaning to store everything in a Secret management tool.
I read the AWS SDK developer guide and understand that there are some standard ways to store AWS credentials like – storing them in environmental variables, credentials file with different profiles and by Using IAM roles for Amazon EC2 Instances.
We don’t run/host our application in Amazon cloud, we just want to use AWS secrets manger service from AWS cloud. Hence, configuring the IAM roles might not be the solution for us.
Are there any best practices (or) a best place to keep the initial Trust credentials?
If you're accessing secrets from EC2 instance, ECS docker container, Lambda function, you can use Roles with policy that allows access to Secrets Manager.
if IAM Role is not an option, You can use Federation Login to get temporary credentials (IAM Role) with policy that allows access to Secrets Manager.
As #Tomasz Breś said, you can use federation if you are already using an on-premis Auth system like Active directory or Kerberos.
If you do not have any type of credentials already on the box, you are left with two choices: store your creds in a file and use file system permissions to protect them, or use hardware like an HSM or TPM to encrypt or store your creds.
In any case, when you store creds on the box (even AD/Kerberos), you should ensure only the application owner has access to that box (in the case of a stand alone app and not a shared CLI). You should also harden the box by turning off all un-necessary software and access methods.
I would like to know whether it is possible to attached a service account created in my-project-a to a Google Compute Engine instance in say my-project-b?
The following command:
gcloud beta compute instances create my-instance \
--service-account=my-service-account#my-project-a.iam.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--project=my-project-b
gives me the following error:
(gcloud.beta.compute.instances.create) Could not fetch resource:
- The user does not have access to service account 'my-service-account#my-project-a.iam.gserviceaccount.com'. User: 'me#mysite.com'. Ask a project owner to grant you the iam.serviceAccountUser role on the service account. me#mysite.com is my account and I'm the owner of the org.
Not sure whether this is related, but looking at the UI (in my-project-b) there is no option to add a service account from any other projects. I was hoping to be able to add the account my-service-account#my-project-a.iam.gserviceaccount.com
You could follow these steps to authenticate a service account from my-project-a to an instance in my-project-b:
Create a service account in my-project-a with the proper role for compute engine
Download the JSON file.
Copy the my-project-a new service account email
On my-project-b, add a team member by using the copied email from the previous step
Connect via SSH to your instance in my-project-b
Copy the JSON file from the step 2 on your my-project-b instance
Run the following command to activate the service account:
gcloud auth activate-service-account --key-file=YOUR_JSON_FILE
Verify by using the following command:
gcloud auth list
I am facing the following problem.
I have to log in users in Openshift using Keycloak and then these users should be able to use the Openshift API using a custom external Web GUI which I made.
When I log in, Keycloak returns a Keycloak JWT-token. But my problem is that with this Keycloak JWT-token I cant use the Openshift API, for that I need an Openshift token, which is a different token. I could get the Openshift token using an http request to -openshiftmaster-/oauth/authorize , But I don't wanna do this cause this second authentication would mean a second login screen for the user.
Is there a way, once logged in usingKeycloak and in possession of a Keycloak JTW-token, to get the Openshift token without having to authenticate again against Openshift with username and password?
You can set up keycloak as an open id provider. Link 2. Link 3.
As of now, we have an authentication service using Spring Security OAuth2 which implements the following grant types: client_credentials and password.
To obtain a token, a client (potentially an HTML5 SPA client) would have to store the client_id and secret to obtain a bearer token with either the client_credentials or password grant type. For this case, it's not very safe as anyone the client_id and secret would live within the HTML5 apps source and anyone could obtain it.
Is there a different flow for this, other than client_credentials or password?
Generally speaking, for SPA s the recommended authorization protocol is OAth with Implicit grant.
You can read a bit more about how that is implemented in Azure Active Directory (it is free) here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-understanding-oauth2-implicit-grant
and here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-implicit