Quantcast

Security Best practices for multiple repositories

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Security Best practices for multiple repositories

Ryan, Scott D

I have noticed a lot of discussion around the topic of security and I am
encouraged to see it as that is one of the items that differentiates an
enterprise solution from a one off developer solution.  I am in the
midst of converting from Archiva to Artifactory and trying to understand
some best practices.

We have a number of repositories that are hosted on our Artifactory
instance.  We have been trying to understand how to leverage the group
security within artifactory which is much different than that offered in
Archiva.  

First
We have a repository that contains our snapshots that any developer can
deploy artifacts into.  We then have our version repository where our
development managers deploy versioned artifacts of our code into for use
by development staff.  We have an additional repository that our SCM
team deploys artifacts into for use in our non development environments
such as QA, Stage and Production.  The SCM repository must be tightly
locked down for SOX compliance so we only want our SCM team to be able
to deploy to that repository so we have an audit trail there.  Since all
of these artifacts have the same groupid it does not look like the
security within Artifactory will allow us to create these repositories
on the same artifactory instance.  On Archiva we could control
deployment access on a repository by repository basis.  There is
potential to have hundreds of these repositories in the company and I
don't want to have to create an Artifactory instance for each
repository.  Is there a solution for this situation?

Second
We generally allow downloads of any open source tools by most of our
users however some of the artifacts fall under licenses that we want to
restrict to certain users.  It looks like we can use the group
permission to control that.  For example is we deem that org.hibernate
is something we want to restrict we can create a group org.hibernate and
only assign users read authority to that group if they have been
authorized.

Also wanted to check on the status of the LDAP integration as that would
be a great way to integrate our existing development staff rather than
creating 1000's of new user ids.

Thanks for a great product and I look forward to hearing back on my
issue.

Scott D. Ryan
Senior Java Developer/Architect

- - - - - - - - - - - - - - - - - - - - - - - - - -
This message is intended only for the personal and confidential use of the designated recipient(s) named. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Aurora Loan Services. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Security Best practices for multiple repositories

Yoav Landman
Administrator

Thanks for the feedbacks. Much appreciated.
We will be supporting repository-based security (in addition to
groupId-based security) in our upcoming release (1.2.1).
With JCR at the back, auditing should be feasible. What type of audit logs
were you hoping to use?
About LDAP - We realize the need for LDAP integration and for assigning
permissions to LDAP groups, and will definitely include this, but it will
take some time. I created a JIRA issue if you wish to follow up:
https://www.jfrog.org/jira/browse/RTFACT-63


Ryan, Scott D wrote:

>
>
> I have noticed a lot of discussion around the topic of security and I am
> encouraged to see it as that is one of the items that differentiates an
> enterprise solution from a one off developer solution.  I am in the
> midst of converting from Archiva to Artifactory and trying to understand
> some best practices.
>
> We have a number of repositories that are hosted on our Artifactory
> instance.  We have been trying to understand how to leverage the group
> security within artifactory which is much different than that offered in
> Archiva.  
>
> First
> We have a repository that contains our snapshots that any developer can
> deploy artifacts into.  We then have our version repository where our
> development managers deploy versioned artifacts of our code into for use
> by development staff.  We have an additional repository that our SCM
> team deploys artifacts into for use in our non development environments
> such as QA, Stage and Production.  The SCM repository must be tightly
> locked down for SOX compliance so we only want our SCM team to be able
> to deploy to that repository so we have an audit trail there.  Since all
> of these artifacts have the same groupid it does not look like the
> security within Artifactory will allow us to create these repositories
> on the same artifactory instance.  On Archiva we could control
> deployment access on a repository by repository basis.  There is
> potential to have hundreds of these repositories in the company and I
> don't want to have to create an Artifactory instance for each
> repository.  Is there a solution for this situation?
>
> Second
> We generally allow downloads of any open source tools by most of our
> users however some of the artifacts fall under licenses that we want to
> restrict to certain users.  It looks like we can use the group
> permission to control that.  For example is we deem that org.hibernate
> is something we want to restrict we can create a group org.hibernate and
> only assign users read authority to that group if they have been
> authorized.
>
> Also wanted to check on the status of the LDAP integration as that would
> be a great way to integrate our existing development staff rather than
> creating 1000's of new user ids.
>
> Thanks for a great product and I look forward to hearing back on my
> issue.
>
> Scott D. Ryan
> Senior Java Developer/Architect
>
> - - - - - - - - - - - - - - - - - - - - - - - - - -
> This message is intended only for the personal and confidential use of the
> designated recipient(s) named. If you are not the intended recipient of
> this message, you are hereby notified that any review, dissemination,
> distribution or copying of this message is strictly prohibited. This
> communication is for information purposes only and should not be regarded
> as an offer to sell or as a solicitation of an offer to buy any financial
> product, an official confirmation of any transaction, or as an official
> statement of Aurora Loan Services. Email transmission cannot be guaranteed
> to be secure or error-free. Therefore, we do not represent that this
> information is complete or accurate and it should not be relied upon as
> such. All information is subject to change without notice.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Artifactory-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
>

--
View this message in context: http://www.nabble.com/Security-Best-practices-for-multiple-repositories-tf3396401.html#a9464563
Sent from the Artifactory-Users mailing list archive at Nabble.com.



Loading...