How to handle password rotation for kafka acls passwords?
Users cant access the kafka cluster without authentication, we are adding the user(& password) to zookeeper and adding the respective acls for the user.
Now i have a requirement for passwords rotation for these uses passwords which are stored in zookeeper
I don't think you can rotate passwords in that case without a chance of downtime (auth failures).
Ignoring the small chance of auth failures, what you could do is the following:
Change the passwords in the zookeeper using the same command that you had used to create the username/password.
Then, change your applications to use the new passwords.
Downside to this approach is that if your app restarts between steps 1 & 2 (i.e. the zookeeper has been updated with the new password, but the app is using the old password), then the app will get auth failure errors.
Related
For all the auto-generated Kerberos principals, for example HDFS, Hadoop, Livy, how can I get their passwords so that I can try kinit with it?
I created a Kerberized cluster in AWS EMR and by default it auto-generated all these principals, and now I want to actually be able to authenticate Kerberos with them, but I don't know their passwords.
How can I get their passwords, and since I have their keytabs can I get their passwords from the keytabs?
I’m automating a service that needs to access a kerberized resource.
Passwordless kinit with a keytab works fine. The resource is then connected
to using SASL.
Is there a way, maybe via GSSAPI or libkrb5, to ensure a TGT is present
whenever the resource is being accessed? Forking kinit before every access
seems the pragmatic thing to do. However, there’s an obvious race between the
time of TGT acquisition and its use to acquire a TGS that I’d like to avoid.
I imagine something like receiving an fd for authentication whose validity is
guaranteed until it is being closed by the user.
I’d prefer to stay away from heavy-duty solutions like sssd to auto-renew the
TGT.
The answer turns out to be providing the client keytab for libkrb5 in the
KRB5_CLIENT_KTNAME parameter:
If no existing tickets are available for the desired name, but the name
has an entry in the default client keytab, the krb5 mechanism will
acquire initial tickets for the name using the default client keytab.
From the MIT Kerberos docs.
The wiki also has a write-up of the implementation.
I am interested in barring pgAdmin access to my PostgreSQL server from any station other than the server. Is is possible to do this using pg_hba.conf? The PostgreSQL server should still allow access to the server for my application from other stations.
No, this isn't possible. Nor is it sensible, since the client (mode of access) isn't the issue, but what you do on the connection.
If the user managed to trick your app into running arbitrary SQL via SQL injection or whatever, you'd be back in the same position.
Instead, set your application up to use a restricted user role that:
is not a superuser
does not own the tables it uses
has only the minimum permissions GRANTed to it that it needs
and preferably also add guards such as triggers to preserve data consistency within the DB. This will help mitigate the damage that can be done if someone extracts database credentials from the app and uses them directly via a SQL client.
You can also make it harder for someone with your app's binary etc to extract the credentials and use them to connect to postgres directly by:
using md5 authentication
if you use a single db role shared between all users, either (a) don't do that or (b) store a well-obfuscated copy of the db password somewhere non-obvious in the configuration, preferably encrypted against the user's local credentials
using sslmode=verify-full and a server certificate
embedding a client certificate in your app and requiring that it be presented in order for the connection to be permitted by the server (see client certificates
Really, though, if you can't trust your uses not to be actively malicious and run DELETE FROM customer; etc ... you'll need middleware to guard the SQL connection and apply further limits. Rate-limit access, disallow bulk updates, etc etc.
kube-apiserver does not seem to provide an option to use a certification revocation list (CRL).
Is there a way to revoke a client certificate if it's lost or not used anymore?
As far as I know there isn't a way to directly revoke certificates via a CRL. However, what does work, and what we are currently using, is ABAC policies to identify users (set via the Common Name of a certificate), and whether they have access to a given resource on Kubernetes.
As an example, say you have a user called "random". You would generate a Client Certificate for them from your given Certificate Authority, with a Common Name of "random".
From there, you can have an ABAC policy file (a csv file with each line being a bit of JSON), with permissions set for user "random" that would provide them with a certain level of access to the Kubernetes API. You can have them have access to everything or certain namespaces or other API parameters. If you need to revoke permissions, you simply delete that user from the ABAC policy file. We've tested this, and it works well. The unfortunate thing, I will say, is you have to restart the Kubernetes API service for those changes to take effect, so there may be a few seconds of downtime for this change to occur. Obviously in a development environment this isn't a big deal, but on production you may need to schedule time for users to be added.
Hopefully in the future a simple "kube-apiserver reload" will allow for a re-read of that ABAC policy file.
One final thing to note: when using Client Certificates for ABAC authentication, you will need to set permissions for users INDIVIDUALLY. Unlike with auth tokens with ABAC, you cannot set Client Certificate users in "groups." Something that caused us headaches, so figured it was worth passing on. :)
Hope this helps!
I can successfully set up authentication and use it with mongoDB. The issue i'm currently having is that I can't work out how to have authentication set for one database, but not others. For instance, if my databases are:
admin
authenticatedDB
openDB
I would like authenticatedDB to require authentication, whereas I'd like openDB to be freely accessible with no login. Is this possible within MongoDB?
If it's not possible, is there a way to run two separate mongod sessions locally?
Thanks in advance :)
The issue i'm currently having is that I can't work out how to have authentication set for one database, but not others.
Auth (as at MongoDB 2.4) is a global setting, so will be required for all connections once you have enabled authentication and created a user administrator.
If it's not possible, is there a way to run two separate mongod sessions locally?
You can run multiple instances on the same server by specifying different data directories and port values for each mongod. This is definitely not a recommended practice for production environments as multiple mongods will be competing for the same host resources.
As an alternative to running multiple mongods, you could use weak credentials for your openDB (i.e. username and password openDB). Access control in MongoDB 2.4+ uses user privilege roles so your openDB user could be limited to read or readWrite role on the openDB database.