[
https://issues.apache.org/jira/browse/HDDS-13343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sammi Chen updated HDDS-13343:
------------------------------
Description:
After HDDS-8829, dt is signed and verified by secret key generated and managed
by SCM.
Secret key has following configurations and default values,
hdds.secret.key.expiry.duration 7d
hdds.secret.key.rotate.duration 1d
hdds.secret.key.rotate.check.duration 10m
dt has following configurations and default values,
ozone.manager.delegation.token.max-lifetime 7d
ozone.manager.delegation.token.renew-interval 1d
ozone.manager.delegation.remover.scan.interval 1h
It's possible a dt is created near the secret key rotation duration (1 day), in
which case the dt could stay valid much longer than the secret key.
Say a secret key is created at June 1st, 00:00am.
A dt is created using this secret key at June 1st 23:59pm.
The secret key would expire at June 8th, 00:00am and removed from SCM memory by
June 8th, 00:10am.
The dt last renewed at June 7st 23:59pm, would expire at June 8th, 23:59pm and
removed by June 9th 00:59am. So during June 8th, 00:01am to June 9th 00:59am,
if OM restarts, the secret key is not available to calculate the password of
this dt which is still valid.
So secret key cannot be expired and removed from SCM before all its possible
signed dt are expired. To achieve this, dt key configurations must have
dependency on secret key configurations, for example,
1. SCM 1d(rotate), 7d(max), 10m(check) OM 1d(renew), 7d(max), 1h(check)
secret key should expire 7d(dt max) + 1d (sk rotate) + 1h (dt check) > 7d
(sk max) -> will cause issue
2. SCM 1h(rotate), 3d(max), 10m(check) OM 1d(renew), 14d(max), 10m(check)
secret key expire 14d(dt max) + 1h(sk rotate) + 10m( dt check) > 3d (sk
max) -> will cause issue
3. SCM 1d(rotate), 7d(max), 10m(check) OM 1d(renew), 3d(max), 1h(check)
secret key expire 3d(dt max) + 1d(sk rotate) + 1h(dt check) < 7d (sk max)
-> will not cause issue
So overall, the formula to follow is
( dt max + sk renew + dt check ) < sk max
BTW, block token and container token by default doesn't have such problem, for
their lifecycle is
"hdds.block.token.expiry.time 1d" which is far shorter than sk max 7d and
these tokens doesn't persist and doesn't renew.
was:
After HDDS-8829, dt is signed and verified by secret key generated and managed
by SCM.
Secret key has following configurations and default values,
hdds.secret.key.expiry.duration 7d
hdds.secret.key.rotate.duration 1d
hdds.secret.key.rotate.check.duration 10m
dt has following configurations and default values,
ozone.manager.delegation.token.max-lifetime 7d
ozone.manager.delegation.token.renew-interval 1d
ozone.manager.delegation.remover.scan.interval 1h
It's possible a dt is created near the secret key rotation duration (1 day), in
which case the dt could stay valid much longer than the secret key.
Say a secret key is created at June 1st, 00:00am.
A dt is created using this secret key at June 1st 23:59pm.
The secret key would expire at June 8th, 00:00am and removed from SCM memory by
June 8th, 00:10am.
The dt last renewed at June 7st 23:59pm, would expire at June 8th, 23:59pm and
removed by June 9th 00:59am. So during June 8th, 00:01am to June 9th 00:59am,
if OM restarts, the secret key is not available to calculate the password of
this dt which is still valid.
So secret key cannot be expired and removed from SCM before all its possible
signed dt are expired. To achieve this, dt key configurations must have
dependency on secret key configurations, for example,
1. SCM 1d(rotate), 7d(max), 10m(check) OM 1d(renew), 7d(max), 1h(check)
secret key should expire 7d(dt max) + 1d (sk rotate) + 1h (dt check) > 7d
(sk max) -> will cause issue
2. SCM 1h(rotate), 3d(max), 10m(check) OM 1d(renew), 14d(max), 10m(check)
secret key expire 14d(dt max) + 1h(sk rotate) + 10m( dt check) > 3d (sk
max) -> will cause issue
3. SCM 1d(rotate), 7d(max), 10m(check) OM 1d(renew), 3d(max), 1h(check)
secret key expire 3d(dt max) + 1d(sk rotate) + 1h(dt check) < 7d (sk max)
-> will not cause issue
So overall, the formula to follow is
( dt max + sk review + dt check ) < sk max
BTW, block token and container token by default doesn't have such problem, for
their lifecycle is
"hdds.block.token.expiry.time 1d" which is far shorter than sk max 7d and
these tokens doesn't persist and doesn't renew.
> dt configuration dependency on secert key configuration
> -------------------------------------------------------
>
> Key: HDDS-13343
> URL: https://issues.apache.org/jira/browse/HDDS-13343
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Sammi Chen
> Assignee: Sammi Chen
> Priority: Critical
>
> After HDDS-8829, dt is signed and verified by secret key generated and
> managed by SCM.
> Secret key has following configurations and default values,
> hdds.secret.key.expiry.duration 7d
> hdds.secret.key.rotate.duration 1d
> hdds.secret.key.rotate.check.duration 10m
> dt has following configurations and default values,
> ozone.manager.delegation.token.max-lifetime 7d
> ozone.manager.delegation.token.renew-interval 1d
> ozone.manager.delegation.remover.scan.interval 1h
> It's possible a dt is created near the secret key rotation duration (1 day),
> in which case the dt could stay valid much longer than the secret key.
> Say a secret key is created at June 1st, 00:00am.
> A dt is created using this secret key at June 1st 23:59pm.
> The secret key would expire at June 8th, 00:00am and removed from SCM memory
> by June 8th, 00:10am.
> The dt last renewed at June 7st 23:59pm, would expire at June 8th, 23:59pm
> and removed by June 9th 00:59am. So during June 8th, 00:01am to June 9th
> 00:59am, if OM restarts, the secret key is not available to calculate the
> password of this dt which is still valid.
> So secret key cannot be expired and removed from SCM before all its possible
> signed dt are expired. To achieve this, dt key configurations must have
> dependency on secret key configurations, for example,
> 1. SCM 1d(rotate), 7d(max), 10m(check) OM 1d(renew), 7d(max), 1h(check)
>
> secret key should expire 7d(dt max) + 1d (sk rotate) + 1h (dt check) >
> 7d (sk max) -> will cause issue
> 2. SCM 1h(rotate), 3d(max), 10m(check) OM 1d(renew), 14d(max), 10m(check)
> secret key expire 14d(dt max) + 1h(sk rotate) + 10m( dt check) > 3d (sk
> max) -> will cause issue
> 3. SCM 1d(rotate), 7d(max), 10m(check) OM 1d(renew), 3d(max), 1h(check)
> secret key expire 3d(dt max) + 1d(sk rotate) + 1h(dt check) < 7d (sk
> max) -> will not cause issue
> So overall, the formula to follow is
> ( dt max + sk renew + dt check ) < sk max
> BTW, block token and container token by default doesn't have such problem,
> for their lifecycle is
> "hdds.block.token.expiry.time 1d" which is far shorter than sk max 7d and
> these tokens doesn't persist and doesn't renew.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
