Thanks Gabor, reducing the attack vector looks a fair call here.
However, I am still thinking of other ways to eliminate this security concern.
Is there a way I can use ticketCache inside my pods somehow? Maybe something
like Yarn?
Just thinking out loud, but would there be a case of automating the kinit
command to renew the TGT every 24h or creating a new TGT every 7 days without
prompting the user for the password?
Any leads will be helpful as I have seem to hit a dead end :)
Thanks
On Friday, 15 September, 2023 at 03:35:55 pm IST, Gabor Somogyi
<gabor.g.somo...@gmail.com> wrote:
Hi Chirag,
Couple things can be done to reduce the attack surface (including but not
limited to):* Use delegation tokens where only JM needs the keytab file:
https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/security/security-delegation-token/*
Limit the access rights of the keytab to the minimum* Rotate the keytab time
to time* The keytab can be encrypted at rest but that's fully custom logic
outside of Flink
G
On Fri, Sep 15, 2023 at 7:05 AM Chirag Dewan via user <user@flink.apache.org>
wrote:
Hi,
I am trying to implement a HDFS Source connector that can collect files from
Kerberos enabled HDFS. As per the Kerberos support, I have provided my keytab
file to Job Managers and all the Task Managers.
Now, I understand that keytab file is a security concern and if left unsecured
can be used by hackers to gain access to HDFS.
So I wanted to understand if there's a way to encrypt this file on storage (at
rest) and later decrypt before JM and TMs can initialize the KerberosModule?
Or if there any other standard practices in controlling the keytab access from
Storage. Would appreciate some ideas.
Thanks
