We are facing issue with fetching secrets from Hashicorp Vaullt. Client is actually using role_id and secret_id to auth in Vault. We also use wrapping function for secret_id, so once secret_id is fetched from Vault, it's wrapped and has to be unwrapped to get real secret_id.
Now problem is that wrapping token obtained from Vault has number of usage 1. Meaning that secret_id can be unwrapped only once. When we try 2nd time to unwrap, it is failing. And reason is number of usace for such generated token which is 1 by default.
Key Value
--- -----
accessor LctZYfQyzJVleDb41l7mACu5
creation_time 1603924396
creation_ttl 240h
display_name n/a
entity_id n/a
expire_time 2020-11-07T22:33:16.378745728Z
explicit_max_ttl 240h
id s.ajjvwjfjtTedj7xaeGW1B1WL
issue_time 2020-10-28T22:33:16.378758503Z
meta <nil>
num_uses 1
orphan true
path auth/approle/role/img/secret-id
policies [response-wrapping]
renewable false
ttl 239h58m30s
type service
This is making a lot of issues for us. Is there a way to increase, or set as unlimited number od wrap token usage?
Thank you!
The point of wrapping is that it is only unwrappable once. If you want a token that allows access to a secret for an extended period, then you want a 'regular' token. So create a policy that allows access only to the secret_id, create a new token with only that policy attached, and store that token. Now you have a token that you can use to request the secret_id secret from Vault.
Related
I'm having hard time understanding OIDC that I'm asking here.
[Current Understanding]
ID Token (Based on JWT)
[REQUIRED]
iss (Issuer) : OPurl
sub (Subject Identifier) : unique identifier
aud (Audience) : Unique Client ID which OP provides beforehand
exp (Expires at) : When token expires
iat (Issued at) : When token is issued
[OPTIONAL]
nonce : string value used to associate a client session with ID token (REQ for Implicit Flow)
preferred_username : Shorthand name by which the End-User wishes to be referred to at the RP (The RP MUST NOT rely upon this value being unique)
Sample Token
{"access_token":"SlAV32hkKG","token_type":"bearer","expires_in":3600,"id_token":"eyJ0...","refresh_token":"8xLOxBtZp8"}
Authorization Code Flow (/authorize GET => /token POST) : contains refresh_token and is in JSON form
Implicit Flow (/authorize GET) : does not contain refresh_token and is responsed in fragment mode
Sample ID Token
Header (Base64 Decoded) : {"typ":"JWT","alg":"RS256","kid":"sdfikhRETlknsdfollksdf324lhk"}
Payload (Base64 Decoded) : {"iss":"OPurl","aud":"ClientID","sub":"1234567890","exp":"1665666710","iat":"1665666790"}
Signature : ggW8hZ...zqg
[Question]
In OIDC Core Spec, sub(subject identifier) is a "locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client".
In JWT Spec, it can either be locally unique in the context of the issuer or be globally unique.
Here I have a globally unique User ID. (Let's say 1234567890)
User uses this ID for client A, B, C... everywhere.
No others can use this ID.
Can sub be that ID itself? ("sub":"1234567890")
Or Should sub be like a mix of a random string with the id and preferred_username should be the ID itself? (Keycloak for example, returns the token like {"sub":"f:636436-348762gyu-234786234:1234567890", "preferred_username":1234567890})
I'm not really sure what it means to be "never reassigned identifier within the Issuer for the End-User"...
Any help would be appreciated.
Please let me know if my current understanding is wrong!
I am going to answer with the assumption you are the developer of a JWT producer.
Based on your comments you may also be the developer of the JWT consumer, which makes me wonder why you are choosing OIDC/JWT for this single identity flow. Either way I will respond with context of producer where the consumers are multiple identities authenticating with you, an identity provider, and you are simply coding the OIDC as an JWT producer.
Here I have a globally unique User ID. (Let's say 1234567890)
This is not appropriate if:
a) this user input of any kind (they register their own username)
b) the user may edit (or request an edit) to the value, e.g. an email address or user handle as a username
c) the numeric example it taken literally, the identifier should not be sequential or attackers can enumerate them easily.
It is common the aud and sub are kept associated in server persistent state, and later the JWK identifier (kid) will be set from the key alias (aud or sub for consistency and simplicity) in the store.
Therefore it is quite important to make the sub immutable, server generated, and this will help you to never orphan a key that would cause significant issues in practice.
It means that the subject identifier is a value that should never ever change.
It should be a unique value within your system.
Unlike preferred_username or email or name.
Using CloudFormation YAML While Creating a KMS key and assigning I want to provide user role ARN in a way that it uses some prefix say "SOME_TEXT.*". Which basically means whatever user roles starts with SOME_TEXT should be allowed to decrypt the data using this KMS key. How do I do that.
Currently this is what I am doing
!Sub "arn:aws:iam::${AWS::AccountId}:role/${AWS::StackName}-SOME_TEXT-*".
But getting Error as one or more invalid principal values.
I have an API Token that I am storing in an Azure Key Vault. I want to provide access to this secret so it can be used from various pipelines. But I don't necessarily want anyone editing/executing those pipelines to be able to retain the Token. If a pipeline just echoes the secret value then won't the build agent logs simply display it, making the whole key vault process a useless step?
If that is the case, is there a way to safeguard a value if I don't necessarily want to trust everyone that can create pipelines?
It depends on how the secret is being retrieved and turned into a variable. In general, secrets retrieved via the standard Azure Pipelines tasks will be masked as **** when being displayed.
However, there's nothing to stop someone malicious from base64 encoding the value and printing it. Or ROT encoding it. Or reversing it. Or splitting the string in half and printing both halves. Or running a script that does this: az keyvault secret show. And so on and so forth.
If there's a secret value in memory as plain text, and people have the ability to manipulate the environment on which the secret is stored in memory as plain text, it's trivial to get the plaintext value of the secret. That's true for any computer under any circumstances.
If this is a concern, by far the best approach is to not have pipelines read secrets. If your application can be configured to integrate directly with keyvault and retrieve the secrets as needed at runtime, there's no need to have the pipeline retrieve the secret as an intermediate step.
When working with Hashicorp Vault one can see token details with
vault token lookup --accessor secret
but is it possible to actually see this token's value ?
No, you cannot. This is for security reason. Otherwise, you will not be able to create a new (child) token and share it with someone, cause in this case lookup will be able to reveal your (parent) token, that is not acceptable.
In general, the output for lookup command contains id part. This is the token value. For lookup command with --accessor flag id is always n/a in response.
Im looking at the new Keycloak Beta 4 API. When i get the users account information, what is referred to as 'id' in the web ui comes back as 'sub' in the account object.
{ sub: '25a37fd0-d10e-40ca-af6c-821f20e01be8',
name: 'Barrack Obama',
preferred_username: 'obama#whitehouse.gov',
given_name: 'Barrack',
family_name: 'Obama',
email: 'obama#whitehouse.gov' }
What is 'sub' and is this a safe uuid to map database objects to?
As per the keycloak documentation
Anatomy of Action Token
Action token is a standard Json Web Token signed with active realm key where the payload contains several fields:
typ - Identification of the action (e.g. verify-email)
iat and exp - Times of token validity
sub - ID of the user
azp - Client name
iss - Issuer - URL of the issuing realm
aud - Audience - list containing URL of the issuing realm
asid - ID of the authentication session (optional)
nonce - Random nonce to guarantee uniqueness of use if the operation can only be executed once (optional)
Please refer the following link https://www.keycloak.org/docs/latest/server_development/index.html#_action_token_anatomy
Reason may be they want to retain the uniqueness in the name.
In addition to the previous answer, inside JWT tokens, sub refers to subject. The reason is that those tokens can be used in various cases, including authorization. That means that id sometimes might not be "the unique identifier" but might be anything, including repeatable destinations. Basically, a naming convention JWT follows, regardless of Keycloak.