Is there a way to restrict Airflow Connections so that they're only visible to the a particular role?
In particular I would like a solution so that a user for a particular role can:
Can only access those connections that are assigned to their role
Can only view those connections that are assigned to their role
I have looked at the following page and there's no instructions there on how to accomplish this:
https://airflow.apache.org/1.10.1/howto/manage-connections.html
You can add these restrictions through RBAC, but not to specific connections, it's all connections or none. To enable RBAC, you will need to either be version 1.10+ and set rbac = True under [webserver] as noted in https://github.com/apache/airflow/blob/master/UPDATING.md#new-webserver-ui-with-role-based-access-control. See the documentation for RBAC in https://airflow.apache.org/security.html#rbac-ui-security for more details on the feature.
The relevant permissions to you are Connections and ConnectionModelView. Then an extra step would be to use DAG level access to ensure certain users can't access DAGs that use certain connections (1.10.2+ only, see https://github.com/apache/airflow/blob/master/UPDATING.md#dag-level-access-control-for-new-rbac-ui).
Related
I am a beginner on mosquitto (Alpine Linux machine)
After several searches I did not find the answer
I would like to authorize MQTT messages only from one device in the network
I tried changing "aclfile.example" to "acl.acl"
user "equipment IP"
topic test
But this did not restrict the connection to only this equipment (The server can still receive messages from others)
Ideas?
There are several things that probably need covering here:
Mosquitto ACLs deal in users and topics, not IP addresses.
By default (at least until v2.0.0 shipped this week) mosquitto allows clients to connect without specifying a username/password. You can disable this by adding allow_annonymous false to the config file
Just renaming the example ACL file will not cause it to be loaded, you need to explicitly point to it in the config file with the acl_file directive.
You will also need to specify a password file with the password_file if you want to ensure that a specific username can only be used by authorised clients.
If you really want to limit access to a single local machine then you may do better looking to user the firewall to only accept external connections from that IP address using the firewall. e.g. iptables on Linux.
There are a couple of ways to do this. The easiest would be to define one user, and disable anonymous access. Your mosquitto.conf file would look like this:
port 1883
allow_anonymous false
password_file /etc/mosquitto/pwfile
You might have other options in your config file for things like logging and persistence, but these lines would only let clients that had the user/password connect. You then set your one username/password up in the pwfile file. Here's a great blog post about how to do that: http://steves-internet-guide.com/mqtt-username-password-example/
Keep in mind that your client node now has to also provide the username/password on the CONNECT packet, or be denied access.
Another way would be to issue an SSL cert to your client, and only allow that cert in. Again, Steve has a great blog post about how to set that up: http://www.steves-internet-guide.com/creating-and-using-client-certificates-with-mqtt-and-mosquitto/
CfnMicrosoftAD creates a security group - see https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html I need to allow outbound UDP access on port 1812 to a server in the same VLAN (ie. add an outbound custom rule to the security group), but cannot work out how to do this using cdk. How can I reference the security group created?
You might be able to use an AwsCustomResource to make an api call to describeDirectories and pull out the securityGroupId from the vpcsettings and use it with a call to SecurityGroup.fromSecurityGroupId to then modify it.
I am in the process of switching the LDAP backend that we use to authenticate access to Gerrit.
When a user logs in via LDAP, a local account is created within Gerrit. We are running version 2.15 of Gerrit, and therefore our local user accounts have migrated from the SQL DB into NoteDB.
The changes in our infrastructure, mean that once the LDAP backend has been switched, user logins will appear to Gerrit as new users and therefore a new local account will be generated. As a result we will need perform a number of administrative tasks to the existing local accounts before and after migration.
The REST API exposes some of the functionality that we need, however two key elements appear to be missing:
There appears to be no way to retrieve a list of all local accounts through the API (such that I could then iterate through to perform the administrative tasks I need to complete). The /accounts/ endpoint insists on a query filter being specified, which does not appear to include a way to simply specify 'all' or '*'. Instead I am having to try and think of a search filter that will reliably return all accounts - I haven't succeeded yet.
There appears to be no way to delete an account. Once the migration is complete, I need to remove the old accounts, but nothing is documented for the API or any other method to remove old accounts.
Has anybody found a solution to either of these tasks that they could share?
I came to the conclusion that the answers to my questions were:
('/a/' in the below examples is accessing the administrative endpoint and so basic Auth is required and the user having appropriate permissions)
Retrieving all accounts
There is no way to do this in a single query, however combining the results of:
GET /a/accounts?q=is:active&n=<number larger than the number of users>
GET /a/accounts?q=is:inactive&n=<number larger than the number of users>
will give effectively the same thing.
Deleting an account
Seems that this simply is not supported. The only option appears to be to set an account inactive:
DELETE /a/accounts/<account_id>/active
How can I restrict publishing to only selected users on a Mosquitto MQTT broker?
I want some users to be able to subscribe, some other users to be able to publish and I need these two groups of users separated.
I know there is an authorization control that allows access with username:password. But it is not clear to me how to assign roles to users.
If there are no such role assignments, is setting different ports for publishers and subscribers possible?
The man page for the mosquitto config file covers all this.
The acl_file option specifies the file that holds the ACL list. The file contains groups of entries that control access to either a topic or pattern to match against a topic. e.g.
user user1
topic read foo/bar
user user2
topic readwrite foo/bar
This allows user1 to read from topic foo/bar and allows user2 to both read and write to the topic.
The password_file option can be used to specify the file to find username/password mappings. This file is edited with the mosquitto_passwd command, here is it's man page.
Both these options can be replaced by a plugin that provides an API to authenticate and authorize users. At the moment there is only one publicly available plugin that supports multiple different database backends to store user/acl data. You can find it here
I'm setting up flexlm (Flexara Software - http://www.flexerasoftware.com) with limited licenses for a compiler. I have been asked to setup flex options to RESERVE one license for a user on a build host. This user is a build account that is not to be RESERVED on any other build host. I can't seem to find an option to RESERVE user#host.
Any ideas how I can get this done?
I know this has been sitting here for a while, but I want to provide an answer since I've been up the same creek many times with FlexNet Options Files.
The RESERVE keyword is only for users, so you would have to do something with INCLUDE or EXCLUDE.
INCLUDE compilerfeature USER buildaccount
INCLUDE compilerfeature HOST buildserver
The above statements do two things:
The first line allows the buildaccount to access the feature on any host to which they are logged in.
The second line allows access to the license if the user is logged into the buildserver.
So, implicitly, only the buildaccount can access the feature from the buildserver.
Unfortunately, this prevents other users from accessing the features, so you will probably want to create groups of users and hosts and use the RESERVE keyword to save one license for the buildaccount.
If there is a specific keyword in the license file that would identify a single license, you can also use that to allow access to a single license by a single user and/or host.