I have a service account with annotation eks.amazonaws.com/token-expiration: "900", but the pods using that service account are getting a token $AWS_WEB_IDENTITY_TOKEN_FILE that is valid for 3600 seconds. I can see that by parsing the jwt in $AWS_WEB_IDENTITY_TOKEN_FILE and by looking at the kubernetes pod manifest that say expirationSeconds: 3600 in the .volumes[0].projected.sources[0].expirationSeconds
I can set the expiration to longer values between 3600 and 86400, so I guess that there is some setting that prevents setting the expiration to lower limits like 15 minutes.
My question is where is that limit coming from? Is that hardcoded somewhere? Is is configurable in some way?
Related
I am trying to learn istio. I was able to setup a simple traffic shifting in which 40 percent traffic goes to a particular version and the remaining 60 percent to other version. My doubt is can I make this weight(40-60) dynamic, based on
Percentage of error response from both the versions. The version with less error response faces more traffic and eventually 100 percent.
Or atleast, change with time, example 2 percent shift every hour.
Also, would this require me to do kubectl apply again and again.
For the first part, there are no features to make a VirtualService route based on error rates in Istio. The routing is based on the number of requests coming through the VirtualService.
Secondly, given that Kubernetes objects are persistent entities and the Istio's CRDs controlling the weight-based routing have its settings defined in the spec of the object (of which state must be provided by the user), it's unexpected that this configuration would change dynamically.
For your scenario, I would say that deploying a new version without knowing if it will error more than the previous one, and expecting them to error enough to decide which is to persist may not be the best approach.
I'd recommend using traffic mirroring for testing the production traffic in the new version, and from that, determinig if is worth deploying it using any existing/supported deployment strategy.
I'm sending messages over GCM with TTL=15 - and they arrive just fine. Despite that fact, the developer console (where GCM messages can be tracked) show status=expired.
According to Google's docs, expired means:
Reached their time-to-live (TTL) and expired.
Am I doing something wrong? Perhaps I'm not acking the message on my Android app?
As Reference;
time_to_live: This parameter specifies how long (in seconds) the message should be
kept in GCM storage if the device is offline. The maximum time to live
supported is 4 weeks, and the default value is 4 weeks. For more
information, see Setting the lifespan of a message.
So 15 seconds are too short to track you may want to increase this value.
I was going through this draft to undertstand usage of REST api to access TURN servics. I am bit confused after going through that.
Currently, I am authenicating my TURN server using Long Term Credential Mechanism with Redis database, but instead of using actual username and password, I am using a authenication token( which expires in 8 hours) and a random string as password.
My doubts about the draft are:
the ttl recieved in the response is never used( at least not part of RTCPeerConnection). so how exactly is TURN know when to expire the user?
I see no option in turnserver arguments to specify the timestamp format, ss it is fixed a UNIX timestamp?
Does REST api implementation offer any advantage over my implementation( considering the fact the mine doesn't have a dependency on sync between webrtc server and TURN server time)
The timestamp generated by the REST endpoint as part of the username is ttl seconds in the future. So the TTL in the response is just informative.
The advantage of the overall approach is that (assuming time sync which is a solved problem) it requires no communication between the entity that generates the token and the TURN server. When deploying multiple TURN servers around the globe (see later in this I/O 2015 presentation) this is somewhat easier than syncing a redis database.
I read in MS msdn site [Link] about the Shared Key Lite authentication scheme for the azure storage service access . It was mentioned that Shared Key Lite signature is valid for 15 mins, this avoids the replay attacks. But my question is, why such a long duration for validity? During 15 mins time span replay attacks can happen right?
But my question is, why such a long duration for validity?
Think of this 15 minutes as a buffer to take care of any clock skewness. It may be entirely possible that the clock on the machine from where you're creating the authorization header is not in sync with clocks in Windows Azure and you obviously don't want exact time match between the 2 systems for the authorization to succeed.
http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime
says that a session.cookie_lifetime of 0 "goes until the browser is closed". Is that the absolute maximum length that the session can have (always wiped when the browser is closed), or would setting a session.cookie_lifetime of, say, 23243245234 yeild a result that would probably last beyond whenever the browser is closed?
More to the point, what php.ini settings would I need to set to make sessions last somewhere along the lines of two days, and is there a security reason to recommend a certain (I would expect lower) time limit, and if so what would the recommended period be?
Intended behavior
Edit: Here is what I want to achieve, perhaps I'll be able to understand the behavior by getting some settings suggestions as opposed to the specific values of the php.ini settings:
I want the session to last as long as possible, up to (approximately) two days.
If the session can last beyond browser close, I would like it to do so (up to approximately two days).
What would I set for php.ini settings (and yes, I have direct edit access to the php.ini) to acheive that?
There are two parameters you need to worry about regarding sessions. The first is the TTL for the cookie, the other is how old a session data file can become before it gets garbage collected.
session.cookie_lifetime determines, in seconds, how long the cookie sent to the browser will last. It defaults to 0, which means until the browser closes. For two days it'd need to be 172800 seconds.
session.gc_maxlifetime determines, also in seconds, how long before session data marked on the server will be regarded as garbage and can be deleted.
Setting these two ini directives should give you sessions that survive for two days, except for one more thing of which you need to be aware.
Some operating systems do automated garbage collection on their default temporary directories. If PHP is configured to store session data there, then if the GC period for the temp directory is short you may find yoruself losing your session before the value in session.gc_maxlifetime is reached. To avoid this, make sure PHP is storing session data to a location other than /tmp or whatever the temporary directory of your host operating system is.
It means that the session is lost at the time the browser gets closed.
That is, the cookie containing that session id gets deleted together with the onclose event of the browser.
session.cookie_lifetime specifies the
lifetime of the cookie in seconds
which is sent to the browser
The recommended period depends basically on what your session needs to hold. Say you want to keep your user logged in the website (remind me), you should go for the largest period. Just as an example.
If you want the session alive for approximately two days, you just count
60 [seconds] * 60 [minutes] * 48 [hours] = 172800 seconds
First off I do not recommend to anyone that they play around with session life unless they are aware of the consequences.
In regards to the your question there are actually two systems in place to manage a session.
Firstly if you are using PHP's default system you are employing a file based session system where by a file is created on your server which holds the actual data of the clients session, this file is normally named the same as the session id. The user then has a cookie send to there browser which holds the session id client side.
The setting you are referring to ONLY defines the life of the cookie in the clients browser not the life of the session.
A setting of 0: causes the cookie to last until the browser is closed.
A setting higher than 0: causes the session to last that many seconds and is only terminated after that time. The browser can be opened and closed as many times as the user wants and the cookie will remain until the time of expiry.
I believe but could be wrong that the setting is only the number of seconds from when the cookie is created and not an actual timestamp but I could be wrong.
You can change this setting in your php.ini or you can use a combination of session_get_cookie_params and session_set_cookie_params
Clarification
Ignoring server side. The client holds a cookie which holds the SessionID and allows them to access there session. If the cookie is lost the client no longer has the ability to access the session and is in essence lost.
A value of 0 will cause the clients browser to keep the cookie until the browser is closed. If the user was to keep there browser open for a week, the cookie would be kept for a week.
A value greater than 0 will cause the clients browser to keep the cookie for that number of seconds. E.g. If the value was set to 172800 seconds (2 days) the cookie would be held by the browser for 2 days. If the browser is closed during this 2 days the cookie is not destroyed, it is only lost after 2 days.
Why use 0
Using 0 is more secure because when a user has finished using your website on a public system and close the browser the cookie is lost and the session can no longer be accessed preventing another user from opening the browser and continuing the session. It is not reliable to presume that a user will end the session manually (e.g. logout) as many don't.
Wait there is the confusion .....
"Session" will not lost if the the browser get closed....its the "Cookies" which get lost on close of browser.
"Session" is altogether is different from "Cookies". Session stays at server and can be destroyed explicitly. Whereas "Cookies" resides at client end and can be destroyed manually or at a particular time interval or on browser close.
Short (but slightly inaccurate) solution
Set session.gc_maxlifetime to 172800 and session.cookie_lifetime to 0.
Extended and more accurate solution
In general, session.gc_maxlifetime is the configuration to control the session’s life time. So setting that directive to 172800 will make the session to expire after 172800 seconds (theoretically). But as the calculation of the age of a session is slightly odd, you might want to implement a more accurate expiration scheme. See my answer to How do I expire a PHP session after 30 minutes? for more information.
And setting the session ID’s cookie lifetime to 0, the cookie will be valid until the browser is closed.